av9ash/GitBugs huggingface dataset:
Bug: compose.setComposeDetails does not detect citations in plaintext
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-11-02 17:39:30+00:00
Resolved: 2023-01-24 17:16:15+00:00

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

In an addon call something like

let details = await messenger.compose.getComposeDetails(tab.id);
messenger.compose.setComposeDetails(tab.id, {
    plainTextBody: details.plainTextBody
});


Actual results:

When in plaintext composition mode, citations in the original message are not detected as such and wrap around on long lines. Color highlighting is also removed.


Expected results:

The message in the composer window should appear as it was, permitting programmatic modifications to it without destroying the formatting otherwise.

The reason seems to be that setting plainTextBody is treated like a manual select-all + cut + paste which has the same effect. Instead, citation marks should be detected, and corresponding lines should be treated like on the composer window setup when replying.

See also https://github.com/4ch1m/mozext/issues/15
Bug: Intermittent comm/mail/test/browser/message-header/browser_phishingBar.js |  rejection: can't access property "getElementsByTagName", msgFrame.contentDocument is null - stack: getBodyElement@chrome://openpgp/content/ui/enigmailMessengerOverlay.js:1372:5
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2020-11-02 21:01:01+00:00
Resolved: 2020-11-15 00:50:55+00:00

**Filed by:** mkmelin+mozilla [at] iki.fi
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=320505288&repo=comm-central
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Io57YuecR_mBwGdNV9jpEQ/runs/0/artifacts/public/logs/live_backing.log

---
```
Maybe from bug 1672851```
Bug: Since the last update, it has become impossible to send an email.
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-11-02 22:32:47+00:00
Resolved: 2020-11-05 13:26:14+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36

Steps to reproduce:

I just updated the Thunderbird to version 78.4.0.


Actual results:

Since the last update, it has become impossible to send an email. I always get the message: "The remote system uses an unsupported version of the security protocol. The configuration related to smtps.uol.com.br needs to be corrected". The problem is that the configuration is correct in Thunderbird.


Expected results:

It should be able to send emails normally.
Bug: messageDisplayScripts on TB 78.4: content script initially fails to run in main 3-pane window
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-11-02 23:22:30+00:00
Resolved: 2021-04-26 14:51:30+00:00

### Bug

The `messageDisplayScripts` display API was introduced in Thunderbird 82 and then backported to ESR 78.4, see bug 1504475.

On Thunderbird 82, the API works fine.

On Thunderbird 78.4, registering a content script with `messageDisplayScripts.register()` does not always behave as expected. Let's consider the minimal reproducer add-on below.

### Reproducer

manifest.json
```json
{
  "manifest_version": 2,
  "applications": {
    "gecko": {
      "id": "test@thunder.bird",
      "strict_min_version": "78.4.0"
    }
  },
  "name": "test",
  "version": "1.0.0",
  "permissions": [
    "messagesModify"
  ],
  "background": {
    "scripts": [
      "background.js"
    ]
  }
}
```
background.js
```javascript
browser.messageDisplayScripts.register({
    js: [{
        file: "content.js",
    }]
});

```
content.js
```javascript
console.info("Test content script executed");
```
### Expected behaviour

This should log the string to the console each time a message is displayed in Thunderbird.

### Actual behaviour

After this add-on has been installed on Thunderbird 78.4, we can observe that:

* The string is not logged to the console when displaying messages in the main 3-pane window. No error is printed.
* When opening messages in a new window, by right-clicking either on the email account (left panel) or on a message in the list, then the add-on works in the new window and the string is logged when messages are displayed in this new window. For the old window, observations may differ: I observed that the add-on is still not working, but that displaying messages would now log an error (`uncaught exception: Object`) instead of remaining silent. Another user reported that the content script would also work in the first window after opening a new one.
* When changing the layout (classic/wide/vertical) of the main window, then the add-on works (and keeps working if switching back to the initial layout). But this manipulation needs to be done each time Thunderbird is restarted.
* Under certain conditions (Not sure which ones, this has been observed with a more complex add-on), the add-on produces a slightly more verbose error message: `uncaught exception: Object 2 ext-extensionScripts.js:161:12`.

This was tested on fresh profiles, on Linux and MacOS.

### Remarks

To me it looks like something in the main 3-pane window is not initialised as it should be, and this would cause the content script injection to break. Changing the window layout apparently fixes that.

The issue is not present on Thunderbird 82, so there is a good chance this bug has been fixed already, but it may be desirable to identify the fix and to backport it to ESR 78.4+ for the `messageDisplayScripts` to work as expected.

This issue was reported on the GitHub repository for an add-on, [here](https://github.com/Qeole/colorediffs/pull/94#issuecomment-716419134) and [there](https://github.com/Qeole/colorediffs/issues/95).
Bug: Drag and drop of email address(es) from contacts side bar to custom header (mail.compose.other.header) does nothing, should drop csv addresses
Status: NEW
Priority: --
Created: 2020-11-03 00:04:50+00:00
Resolved: 2024-05-17 17:10:09+00:00

+++ This bug was initially created as a clone of Bug #1673579 +++
Thanks to orwel01 who alerted us to this issue in Bug #1673579. Re-filed here for a clean start.

STR

1. Open a new mail compose window
2. Create a custom header (e.g. "qacontact") via **`mail.compose.other.header`** pref
3. Open contacts side bar
4. drag one or more email addresses into the custom header field ("qacontact")

Actual results:

- nothing

Expected results:

- drop addresses as comma-separated plaintext (we don't create pills because custom headers are free-form, but that shouldn't stop us from dropping text at least).

~This may be relevant for Addons like `Send Later` per Bug 1673579 Comment 2, which provides fields for Return-Receipt-To and Dispostion-Notification-To, assuming the addon creates custom headers for that.~ Edit: As orwel01 correctly pointed out, this bug does *not* involve addons, but only using the `mail.compose.other.header` pref.
Bug: Crash in [@ MimePgpe_eof]
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-11-03 00:24:32+00:00
Resolved: 2020-12-05 13:11:07+00:00

I crashed a couple days ago.  I have no steps to reproduce.

Crash report: https://crash-stats.mozilla.org/report/index/3cce6be9-ba51-4d61-a24d-b2bb20201030

Reason: ```EXC_BAD_ACCESS / KERN_INVALID_ADDRESS```

Top 10 frames of crashing thread:
```
0 XUL MimePgpe_eof comm/mailnews/mime/cthandlers/pgpmime/nsPgpMimeProxy.cpp:199
1 XUL MimeEncrypted_parse_eof comm/mailnews/mime/src/mimecryp.cpp:193
2 XUL MimeMultipart_close_child comm/mailnews/mime/src/mimemult.cpp:505
3 XUL MimeMultipart_parse_line comm/mailnews/mime/src/mimemult.cpp:140
4 libmozglue.dylib BaseAllocator::malloc memory/build/mozjemalloc.cpp:4055
5 libmozglue.dylib Allocator<MozJemallocBase>::malloc memory/build/malloc_decls.h:51
6 libmozglue.dylib arena_t::DallocSmall memory/build/mozjemalloc.cpp:3291
7 XUL MimeHeaders_get comm/mailnews/mime/src/mimehdrs.cpp:329
8 XUL MimeMessage_parse_line comm/mailnews/mime/src/mimemsg.cpp:152
9 libmozglue.dylib BaseAllocator::malloc memory/build/mozjemalloc.cpp:4055
```
Bug: Thunderbird startup Crash in [@ mozilla::dom::quota::(anonymous namespace)::PrincipalVerifier::Run] via DoExecuteNextTaskOnlyMainThreadInternal - searching for add-ons
Status: RESOLVED
Priority: P2
Resolution: WORKSFORME
Created: 2020-11-03 02:31:15+00:00
Resolved: 2023-05-17 01:15:19+00:00

in beta 82 and 83 we have some crashes with this signature, which comes via DoExecuteNextTaskOnlyMainThreadInternal

This is my crash report: https://crash-stats.mozilla.org/report/index/d0e790b6-1b98-48b6-ae95-743d10201029

MOZ_CRASH Reason: ```Invalid principal infos found: baseDomain (aaaa://aaaa.aaaaaa.aaa:DDD/) doesn't match passed one ({aDaDDaaD-aDDa-DDDD-DaDD-DaDDaDaDDDaa})!```

Top 10 frames of crashing thread:
```
0 XUL mozilla::dom::quota:: dom/quota/ActorsParent.cpp:10358
1 XUL JS::ClearKeptObjects js/src/jsapi.cpp:1408
2 SkyLight CGSEventSourceForID 
3 XUL nsJSContext::MaybePokeCC dom/base/nsJSEnvironment.cpp:1895
4 XUL mozilla::RunnableTask::Run xpcom/threads/TaskController.cpp:245
5 XUL mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal xpcom/threads/TaskController.cpp:515
6 XUL mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal xpcom/threads/TaskController.cpp:374
7 XUL mozilla::detail::RunnableFunction<mozilla::TaskController::InitializeInternal xpcom/threads/nsThreadUtils.h:577
8 XUL nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1197
9 libmozglue.dylib arena_dalloc memory/build/mozjemalloc.cpp:3377
```
bp-30b05789-6898-400d-9f7f-7f8bb0201102 is someone using linux
Bug: Email moved from Inbox to local folder remains in local folder but also returns to Inbox after a short period of time
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-11-03 03:05:33+00:00
Resolved: 2020-12-30 06:50:11+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; rv:82.0) Gecko/20100101 Firefox/82.0

Steps to reproduce:

I drag emails from the inbox folder and drop them into different local folders.


Actual results:

After a varying amount of time the email reappears in the inbox. When I check the local folder I dropped it into the email is still there. I have to manually delete it from the inbox to remove it from there. As far as I can remember this always happens. I think this began happening less than a year ago after I had been using Thunderbird for several years. It does not keep me from using Thunderbird, but it is a pain and sometimes causes me to move multiple copies of the same email in my local folders.


Expected results:

A copy of the moved email should not have returned to the inbox.
Bug: messages.getFull does not parse pgp-signed multipart email
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-11-03 07:30:59+00:00
Resolved: 2020-12-22 13:41:11+00:00

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

I'm passing this email into messages.getFull():

From: Jan Kiszka <jan.kiszka@web.de>
Subject: Test email
To: Jan Kiszka <jan.kiszka@web.de>
Message-ID: <347e7266-351d-e717-e176-97fdf8cecce6@web.de>
Date: Tue, 3 Nov 2020 08:23:52 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.4.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="4iMfSKO2E11sVBTD1ikLjoFcLlYQWl8MY"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--4iMfSKO2E11sVBTD1ikLjoFcLlYQWl8MY
Content-Type: multipart/mixed; boundary="B8zuQHDOBJNfyZgqRDywhe1uNP4jJluA8";
 protected-headers="v1"
From: Jan Kiszka <jan.kiszka@web.de>
To: Jan Kiszka <jan.kiszka@web.de>
Message-ID: <347e7266-351d-e717-e176-97fdf8cecce6@web.de>
Subject: Test email

--B8zuQHDOBJNfyZgqRDywhe1uNP4jJluA8
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

This is a test.


--B8zuQHDOBJNfyZgqRDywhe1uNP4jJluA8--

--4iMfSKO2E11sVBTD1ikLjoFcLlYQWl8MY
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wmMEABEIACMWIQTKX4wA9fvIVGYBbICK1KxveuXnFAUCX6EFiAUDAAAAAAAKCRCK1KxveuXnFE4c
AJ937ISAU3TARRRsBlV13HBiHiOITACgn0w3xDNreqwZBYjg5OsStLKDbW8=
=NFld
-----END PGP SIGNATURE-----

--4iMfSKO2E11sVBTD1ikLjoFcLlYQWl8MY--



Actual results:

I'm only getting a parts array with one element, "multipart/signed".


Expected results:

The other two parts should have been returned as well, specifically the body.
Bug: Incorrect window height
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-11-03 09:30:33+00:00
Resolved: 2020-11-03 13:44:52+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.93 Safari/537.36 Vivaldi/2.8.1664.40

Steps to reproduce:

Open application


Actual results:

Window ends somewhere too far out of screen bounds. Cannot see whole message list and mail body in fullscreen mode. And its not resizeable to fit in windowed mode either.


Expected results:

Window and its content fits on screen.
Bug: not able to resize main windows
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-11-03 10:43:45+00:00
Resolved: 2020-11-05 13:08:43+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:82.0) Gecko/20100101 Firefox/82.0

Steps to reproduce:

Just after an upgrade to 78.4.0, the main windows can not be resized to the normal Screen size.


Actual results:

Only able to see bottom of long messages by using my both Screen


Expected results:

Be able to see correctly my messages.
Without a second screen, it is a blocker bug.

Please provide :
- a quick fix through a stable version
- or at least workaround.
Bug: Window size wrong with Windows 10, Resizeable impossible
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-11-03 11:44:17+00:00
Resolved: 2020-11-04 14:23:34+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:82.0) Gecko/20100101 Firefox/82.0

Steps to reproduce:

Run Current Version of Thunderbird on Windows 10.
Don't know of any Trigger for the issue.

Thunderbird Version is 78.4.0 (64-Bit)
Windows Version is 10 Version 2004 Build 19041.572


Actual results:

Today I wondered why my Calendar does not show the last row of days. Then I recognized that also the status bar at the bottom is not visible.
The maximize button does not fit the window on screen, the bottom is outside screen.
Also Windows Key + Left or Right does not make the bottom of the window appear, it uses the half of the screen, like expected but the bottom is outside screen.
Using the mouse and trying to grab the top border of the window and pull it down does not work. As soon as one grabs the border and try to pull, the whole window jumps down without resizing.
Firefox and all other programs work like expected.
Windows Restart has not solved the Problem

Thunderbird Version is 78.4.0 (64-Bit)
Windows Version is 10 Version 2004 Build 19041.572


Expected results:

Window resize should work.
Bug: Dialogs and windows in Thunderbird use flat UI even in high-contrast mode
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-11-03 11:54:21+00:00
Resolved: 2020-12-22 14:10:31+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4299.0 Safari/537.36 Edg/88.0.688.0

Steps to reproduce:

1. Enable high-contrast mode in Windows 10, by doing the following:
1.1. Open Windows Settings (Windows+I).
1.2. Go to Ease of access -> High-contrast.
1.3. Turn on the high-contrast mode, using the respective toggle.
1.4. From the "High-contrast theme" combo-box, select "High-Contrast Black".
2. Launch Thunderbird.
3. Invoke some dialogs/windows (e.g. IMAP folder properties, Message Filtering, Add Existing Account, etc.).
4. Take a look at the 4th screenshot in the attached archive, named "004_IE_Tabs-Options.png".
5. Compair how the controls in the Thunderbird dialogs/windows look in high-contrast black mode in comparison with the ones in the "Tabbed browsing settings" dialog for IE, taken from Control Panel ➡ internet Options ➡ "General" tab ➡ "Tabs" button.


Actual results:

The controls in Thunderbird's dialogs/windows use a flat UI even in high-contrast mode, but they should not as Windows does not. Not using a flat UI provides better contrast, by adding contours to the controls.


Expected results:

Thunderbird's dialogs/windows should not use a flat UI in high-contrast mode, so they can provide better contrast.
Bug: If more than one compose window has been opened, calls to compose.getComposeDetails fail
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-11-03 13:35:08+00:00
Resolved: 2020-11-30 20:14:45+00:00

background script to reproduce:

```
browser.windows.onCreated.addListener(listen);

 async function listen(aWindow){
   if (aWindow.type == "messageCompose") {
      console.log("Pass1");
      var details = await browser.tabs.query({windowId:aWindow.id});
      console.log("Pass2 " + details[0].id);
      var composeDetails = await browser.compose.getComposeDetails(details[0].id);       
      console.log("Pass3");
    }  
 }
```
This fails for the second opened compose window.
Bug: "Uncaught TypeError: openConversation is null" while clicking on More button in a message Window.
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-11-03 14:12:21+00:00
Resolved: 2021-01-06 17:08:04+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36

Steps to reproduce:

- Open a message in a new Window
- Click on "More" button



Actual results:

The following exception is thrown each time the button is clicked :
	Uncaught TypeError: openConversation is null
		onShowOtherActionsPopup chrome://messenger/content/msgHdrView.js:3478
		onpopupshowing chrome://messenger/content/messageWindow.xhtml:1



Expected results:

No exception
Bug: RTCPeerConnection.createOffer promise never fulfilled
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-11-03 16:14:19+00:00
Resolved: 2025-02-01 22:29:23+00:00

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:82.0) Gecko/20100101 Firefox/82.0

Steps to reproduce:

I wrote some RTC code and load it as temporary addon. Then open the popup


Actual results:

The promise is never fulfilled


Expected results:

The offer should be created
Bug: New unread mail notification remains in taskbar
Status: UNCONFIRMED
Priority: --
Created: 2020-11-03 19:39:40+00:00
Resolved: 2024-12-04 07:05:15+00:00

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:82.0) Gecko/20100101 Firefox/82.0

Steps to reproduce:

I did nothing. Thunderbird queries new mail every 10 minutes. Once there's one, it downloads it and passes it through some filters (that is possibly the cause of the problem) and puts it into a subfolder if it is work related. IIRC, reading new mail that didn't get moved by the filters removes the notification icon normally, but I am not entirely sure.


Actual results:

After seeing the new/unread mail envelope icon in the taskbar, switch to thunderbird and read the new mail (it opens in new window), but after that, the envelope icon remains in the taskbar and the name of the email accounts remains bold and blue as if there was still unread mail. Howering the mouse over the icon shows in a balloon that there is new mail.
Re-checking for new mail gets rid of the envelope icon again.


Expected results:

Envelope notification icon should have disappeared after reading new mail, as it did in earlier versions.
Bug: window size frozen and out of the screen under Win10
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-11-04 08:49:47+00:00
Resolved: 2020-11-05 13:21:40+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.75 Safari/537.36

Steps to reproduce:

nothing particular, 
the window appears like this after several month of thunderbird usage but since  31/10/20 update


Actual results:

Thunderbird  application window is too big for the screen and it is impossible to resize it even after restart of computer. Part of it is out and not reachable  even by the scroll as it is below the bottom of the screen (see attached picture)


Expected results:

possibility to return to a default defined size of window if it is out of the screen or return to a default smaller size.
Bug: Thunderbird Folder List does not scroll far enough to see all folders
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-11-04 09:02:19+00:00
Resolved: 2020-11-06 19:30:24+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:82.0) Gecko/20100101 Firefox/82.0

Steps to reproduce:

Using the grab part of the scroll bar I scrolled to the bottom of my folder list, but the scrollbar hit the buffer before getting to the end of the folder list.


Actual results:

You can see in the attached screenshot, the scrollbar has hit the end buffer but you can see that there is part of a folder name just poking up at the bottom indicating there is more that can't be seen.  In fact there are another 10 lines still to be shown.


Expected results:

The scroll bar should not have stopped til the actual end of the folder list.
Bug: By accidentally pressing the `Delete` key for a little too long, more messages than expected will be deleted.
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2020-11-04 09:22:03+00:00
Resolved: 2024-08-07 05:05:33+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.183 Safari/537.36

Steps to reproduce:

Press the delete button a little too long


Actual results:

 unwanted emails are deleted.


Expected results:

Only one email should be deleted
Bug: Thunderbird fails to show fake URL when hovering over URL text in scam email
Status: UNCONFIRMED
Priority: --
Created: 2020-11-04 09:25:15+00:00
Resolved: 2021-03-25 18:53:11+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36

Steps to reproduce:

Reading emails found one purporting to be my BT billing notification. Hovering over the URL for the fake BT site did not display the actual URL directed to at the bottom of the window. 


Actual results:

Lack of display of the fake URL at the bottom of the message window.
Reviewing the message source, the URL in question was :
<https://%20bt7.godaddysites.com%20?>


Expected results:

The actual URL of the fake site should have appeared in the status line at the bottom of the message window.
Bug: The "Uncaught TypeError: gFolderDisplay.selectedMessage is null" exception is thrown while switching between folders.
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-11-04 10:01:59+00:00
Resolved: 2021-01-06 16:37:19+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36

Steps to reproduce:

- Disable OpenPGP
- Select a folder containing an encrypted message
- Select the encrypted message and immediately select an empty folder.
	-> Uncaught TypeError: gFolderDisplay.selectedMessage is null
- Return to the folder containing the encrypted message and immediately select an empty folder.
	-> Uncaught TypeError: gFolderDisplay.selectedMessage is null



Actual results:

The following exception is thrown :

Uncaught TypeError: gFolderDisplay.selectedMessage is null
    getSelectedMessageURI chrome://messenger-smime/content/msgHdrViewSMIMEOverlay.js:45
    signedStatus chrome://messenger-smime/content/msgHdrViewSMIMEOverlay.js:65



Expected results:

No exception
Bug: I don't receice news message
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-11-04 10:15:04+00:00
Resolved: 2020-11-05 13:28:12+00:00

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:82.0) Gecko/20100101 Firefox/82.0

Steps to reproduce:

since the new version 78.4.0 i do not receive news messages
I work with win 7 sp1 edition familiale premium 64 bits