av9ash/GitBugs huggingface dataset:
Bug: Thunderbird: Sent Messages Reappearing in Draft Folder On Restart
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-03-09 21:58:35+00:00
Resolved: 2021-11-20 15:14:39+00:00

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

Steps to reproduce:

Wrote mail message in plain-text mode, with or without attachments, sent via POP server. Closed Thunderbird. Restarted Thunderbird. 


Actual results:

Message appeared in both Draft and Sent folders. (This is inconsistent, occurs 15-20% of the time.)


Expected results:

Message should NOT reappear in the Draft folder after it has been sent.

This is an unpredictable issue that may require quite a bit of repetition to replicate. It has occurred on more than one machine; the one common thread is that all of the messages were in "draft" for long enough to autosave prior to sending, but even that has not been consistent (that is, sometimes autosaved messages did NOT reappear in Drafts upon restart).
Bug: Intermittent comm/mail/test/browser/content-policy/browser_viewSource.js | Test timed out -
Status: RESOLVED
Priority: P5
Resolution: WORKSFORME
Created: 2021-03-09 22:56:16+00:00
Resolved: 2022-04-25 06:38:23+00:00

**Filed by:** geoff [at] darktrojan.net
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=332603023&repo=comm-central
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/WEcR-w63TA25VvnpGgsP4A/runs/0/artifacts/public/logs/live_backing.log

---
```
```
Bug: HTML Email with large table with inline image references eats up gigabytes of RAM - loads full mail into memory for each image.
Status: NEW
Priority: --
Created: 2021-03-10 05:48:17+00:00
Resolved: 2023-04-02 23:46:10+00:00

Attached is a mostly-sanitized (but not necessarily minimized) HTML email that was generated from a Confluence page change.  Upon rendering this email message as HTML, Thunderbird uses gigabytes and gigabytes of RAM until the OS is virtually unusable.

I'm using 78.8.1 (64-bit) on macOS Big Sur

Steps to reproduce:
1) Open attached EML file
2) Make sure that messages are viewed in Original HTML

Actual results:
Seemingly unending consumption of available RAM.

Expected results:
Reasonable amount of RAM usage
Bug: Intermittent TEST-UNEXPECTED-TIMEOUT | comm/mail/components/addrbook/test/browser/browser_cardDAV_init.js (finished) | application timed out after 370 seconds with no output
Status: RESOLVED
Priority: P5
Resolution: WORKSFORME
Created: 2021-03-10 06:35:29+00:00
Resolved: 2022-04-04 11:57:13+00:00

**Filed by:** geoff [at] darktrojan.net
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=332643214&repo=comm-central
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/fBLVnYe5Q9OBYkMqyevYAg/runs/0/artifacts/public/logs/live_backing.log

---
```
```
Bug: Compose view does not pick up background colour properly
Status: NEW
Priority: --
Created: 2021-03-10 12:56:15+00:00
Resolved: 2021-05-10 08:51:56+00:00

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.186 Safari/537.36

Steps to reproduce:

Thunderbird on Ubuntu. Using "Default" System Theme (dark from the OS).
I've configured Preferences > General > Language & Appearance > Fonts & Colours > Colours...: Text black, Background white (screenshot).


Actual results:

Background in compose view is dark (screenshot).
Reader view shows expected white background.
When changing Theme in Add-ons Manager > Themes to Light, compose view changes accordingly. Changing Theme back to System Theme, compose view still shows white background (apparently from the System Theme).
But after next restart compose view background is dark again.


Expected results:

Compose view should show same background color as the reader view (as configured in preferences).
Bug: MessageHeader for nntp messages does not include recipients and ccList
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2021-03-10 15:01:03+00:00
Resolved: 2021-03-24 20:35:45+00:00

This is originally caused by bug 1696895. As long as that is not fixed, we need to add the missing information manually.
Bug: Message window does not close when message is deleted
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-03-10 15:35:34+00:00
Resolved: 2021-11-30 05:12:43+00:00

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

Steps to reproduce:

In Preferences > General > Reading & Display > Open messages in

I have > A new message window and > Close message window/tab on move or delete


Actual results:

When I click the Dustbin (only have icons visible) the message is deleted but the message window remains open, so I have to click the close window X to close it.


Expected results:

The message should be deleted and the message window should close.
Bug: Port bug 1634281 - Remove nsDataHashtable
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-03-10 22:49:19+00:00
Resolved: 2021-03-11 00:49:46+00:00

https://hg.mozilla.org/mozilla-central/rev/d5f05e5ae9ebc2ff8f37b9738457957a174ce1ff
Bug: Renaming an attachment during composition, can't insert characters from keyboard; only the "delete" key works
Status: UNCONFIRMED
Priority: --
Created: 2021-03-10 22:51:33+00:00
Resolved: 2021-05-26 23:11:16+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:86.0) Gecko/20100101 Firefox/86.0

Steps to reproduce:

1) Create a new message (File -> New -< Message)
2) Attach a file
3) Right-click on attached filename
4) Select Rename...
5) In order to change the filename in the dialogue window, press any character key on the keyboard (except delete or backspace) 

Additional information:
A) I am on macOS Big Sur 11.2.1.
B) I use both English input and Japanese input methods; the problem is the same irrespective of the input method


Actual results:

The characters input from keyboard do not appear in the dialogue window and the attachment filename remains unchanged.


Expected results:

The characters input from keyboard should appear in the dialogue window and the attachment filename should be modified accordingly.
Bug: I no long have an inbox on Thunderbird for my ATT mail
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-03-10 23:43:43+00:00
Resolved: 2021-07-18 06:50:48+00:00

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

Steps to reproduce:

Open Thunderbird to read my mail


Actual results:

When I open Thunderbird it only shows Local Folders no inbbox


Expected results:

An inbox should be there
Bug: Intermittent Assertion failure: nsContentUtils::IsSafeToRunScript(), at /builds/worker/checkouts/gecko/docshell/base/nsDocShell.cpp:1507
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2021-03-11 02:13:30+00:00
Resolved: 2021-03-15 21:19:34+00:00

**Filed by:** geoff [at] darktrojan.net
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=332789006&repo=comm-central
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/cRFYc_eMR_6UsWCXcs89uA/runs/0/artifacts/public/logs/live_backing.log

---
```
```
Bug: Primary password with multiple accounts prevents clean exit
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-03-11 15:30:59+00:00
Resolved: 2021-09-10 00:44:41+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.152 YaBrowser/21.2.2.101 Yowser/2.5 Safari/537.36

Steps to reproduce:

Create a profile with several mail boxes on different servers with different passwords, and then enable primary password, this is the key part. Exit, restart, enter the primary password, and exit again. TB will crash on exit.


Actual results:

TB crashes every time on exit: a process is always left running, and apparently dies after some timeout, after which a crash report is produced.


Expected results:

TB should exit cleanly, without a hanging leftover process and without a crash report.
Bug: Pushes to try-comm-central are not executing anything.
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-03-11 17:03:06+00:00
Resolved: 2021-04-06 12:53:44+00:00

On Treeherder I just see complete with not build/test information. 

See this job as an example:
https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=f56c7a4f308e5fd2b368a9d4e777129a1af023d4
Bug: Huge notification bigger than the screen from feed folders observed in TB 78.8.1 notifying of "0 new messages"
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-03-11 18:48:11+00:00
Resolved: 2021-04-22 12:04:41+00:00

I've noticed that in TB 78.8.1, after starting the program, first new mail is notified. After a little while there is a huge feed article notification. This is rather surprising. Seems to be a regression from bug 210148. After that bug, there is now additional notification.

This should be toned down, maybe mitigated by bug 375717, but by the looks of it, the notified feed articles were also new since the last start. At least the notification should be limited to 6-8 messages like we have for mail.
Bug: remove attachments from compose.beginNew(msg.id)
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2021-03-11 20:44:28+00:00
Resolved: 2022-01-21 12:11:08+00:00

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

Steps to reproduce:

if msg.id is supplied, the content of the original mail is copied over.
Using composeDetails, this can be modified. body="", for example, removes the body of the original email from the new mail.


Actual results:

I did not find a method to remove the attachments. That should be possible as well.

There is a workaound: compoase.listMessages followed by removeMessages. Drawback: can only be done after compose window is rendered. So it first comes up with attachments visible, which then (visibly) disappear. That looks unprofessional.


Expected results:

if attachments == null in composedetails: remove the original attachments (or something similiar)
Bug: TB 78.8.1 (32 Bit) under Server Settings only provides POP, but Gmail now requires IMAP.
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-03-12 04:44:27+00:00
Resolved: 2021-03-13 23:42:51+00:00

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

Steps to reproduce:

Open Server Settings.  There is no IMAP option presented.


Actual results:

Gmail refuses login request and complains about poor security in the email client.


Expected results:

An IMAP option should be available in Server Settings, or it should be hardwired for a Gmail account (as POP is now).
Bug: Slow, choppy scrolling in folder pane on Mac
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-03-12 05:48:33+00:00
Resolved: 2023-01-29 19:26:23+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 11_2_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.192 Safari/537.36

Steps to reproduce:

Scroll up/down the folder pane with mouse wheel on Mac.

TB 78.x. There were no issues in earlier versions.
macOS 11.2, 10.15


Actual results:

Scrolling is choppy and slow.


Expected results:

Normal scrolling as in pre-78 versions.
Bug: option to disable the tray icon for feed accounts like it is possible for mail accounts (too many tray notification for new feed updates)
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-03-12 10:37:58+00:00
Resolved: 2021-03-12 18:25:38+00:00

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

Steps to reproduce:

Have a feed account with RSS feeds


Actual results:

Since the auto-update to 78.8.1 (32 bit), every new article update of every RSS feed (both manually and automatically by interval) places the "new mail" envelope icon in the system tray of Windows 10. No sound is played and when hovering over the icon in the tray, there is no additional text (in contrast to real new mails, where it tells you how many new messages there are).

I get feed updates by the minute, so I now disabled automatic checking for feed updates because it is so distracting to have the "new mail" icon popping up all the time. During work, I am required to answer real new mails quickly, so I have to check.


Expected results:

Nothing, there should not be a tray icon for RSS feed updates.

Alternatively, there should be an option to disable the tray icon for feed accounts like it is possible for mail accounts.
Bug: Message list is not focused when Thunderbird launches
Status: NEW
Priority: P3
Created: 2021-03-12 11:59:28+00:00
Resolved: 2023-04-01 11:29:15+00:00

+++ This bug was initially created as a clone of Bug #1629522 +++

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

Steps to reproduce:

Launch Thunderbird. For someone using a screen reader, it now looks as if the focus has landed in an undefined area. To get to the message list, press TAB several times.

Actual results:

After Thunderbird has launched, the focus is not set on the message list. It looks like the focus is in an undefined area. This bug has existed for several years now and needs to be fixed.

Expected results:
Once Thunderbird has launched, the focus should be on the message list of the last selected folder. This happened with all email programs I know. If the focus is set directly on the message list, it is no longer necessary to press TAB several times to get to the message list. This also makes the operation much easier for inexperienced users who use a screen reader.
Bug: Forwarding messages as attachment via drag-and-drop should also obey the "add extension to file name" preference (mail.forward_add_extension)
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-03-12 14:57:04+00:00
Resolved: 2023-06-28 18:56:14+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:86.0) Gecko/20100101 Firefox/86.0

Steps to reproduce:

Drag-and-drop an email message to the Compose window in order to forward it as an attachment, while having un-checked the Composition setting "add extension to file name" next to Forward messages.


Actual results:

The email message is attached using a filename with an .eml extension. (This triggers some email filtering at some ISP, resulting in rejection of the email.)


Expected results:

I would expect the setting "add extension to file name" to affect also drag-and-drop email message attachments, i.e. the behaviour of "Forward as attachment". When "add extension to file name" is unchecked, no .eml extension should be added, but only when it is checked, the extension should be added.
Bug: PDF attachments treated as HTML when opened externally during composition (due to error in PdfStreamConverter.jsm), so users may face hurdles or fail to open the PDF depending on TB and browser settings
Status: ASSIGNED
Priority: P3
Created: 2021-03-12 17:01:32+00:00
Resolved: 2025-01-29 09:17:45+00:00

## Steps to Reproduce

Compose or Edit a message with a pdf attachment.

Open the pdf attachment (through double click or context menu).

## Result

Get popup message

```
You have chosen to open:
    <file>.pdf
    which is: HTML document
```

So the type is HTML, which means you'll likely get a recommendation to open in a browser, rather than the default pdf reader.

Also get the printed error message

```
JavaScript error: resource://pdf.js/PdfStreamConverter.jsm, line 140: TypeError: can't access property "getInterface", requestor is null
```

*Note: opening attachments when viewing a message (not composition), in either a tab or a separate window works fine.*

## Expected

The file to be treated as a PDF and no error message.

## Origin?

Looking in `PdfStreamConverter.jsm`, the error is from `getDOMWindow` (https://searchfox.org/mozilla-central/rev/9ae77e4ce3378bd683ac9a86b729ea6b6bd22cb8/toolkit/components/pdfjs/content/PdfStreamConverter.jsm#136), which is called by `proxy.onStopRequest`. The problem seems to be that both `aChannel.notificationCallbacks` and `aChannel.loadGroup.notificationCallbacks` are `null`.

*Note: opening an attachment in a viewed message (not composing), does not seem to pass through the same code.*

On the the thunderbird side, I've tracked down the trigger for the error to `openURI` in `MsgComposeCommands.js` (https://searchfox.org/comm-central/rev/9bc3ba1480090c4e89d5152e458f19c79b3d6ac4/mail/components/compose/content/MsgComposeCommands.js#7171).

I couldn't really pinpoint the origin much beyond this because the code is passing through interfaces (and probably between c++ and javascript), and I'm not familiar enough to navigate this.

#### Why is it treated as HTML instead?

I think the reason the document is treated as as HTML is a side effect of the JavaScript error. Also in `PdfStreamConverter.jsm`, the `onStartRequest` method changes the `contentType` from `application/pdf` to `text/html` (https://searchfox.org/mozilla-central/rev/9ae77e4ce3378bd683ac9a86b729ea6b6bd22cb8/toolkit/components/pdfjs/content/PdfStreamConverter.jsm#1231). Supposedly, this is done to break some loop. My guess is that it is meant to be set back to `application/pdf` during `onStopRequest`, but this method errors before it can do so.
Bug: Printing an email, the p7m inline attachment does not appear in the list of attachments
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-03-12 17:31:53+00:00
Resolved: 2021-03-19 22:07:37+00:00

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

Steps to reproduce:

tried to print an email with attached files, including ".p7m" file


Actual results:

into inline list the files with ".p7m" extention is not appearing


Expected results:

the list should include also the ".p7m"  as in the past
Bug: nsMsgSearchTerm.cpp:986:20: error: no member named 'IsUtf8' in namespace 'mozilla'
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-03-12 18:00:15+00:00
Resolved: 2021-04-22 12:05:13+00:00

It seems that we're busted as the `nsMsgSearchTerm.cpp` is missing the `#include "mozilla/Utf8.h"`.

Is this a regression?
Patch incoming.
Bug: Partial update on Daily 88 always fails, then does another full update after restart of TB
Status: NEW
Priority: P3
Created: 2021-03-12 18:03:01+00:00
Resolved: 2024-07-20 18:03:46+00:00

Something which I've seen on Daily for a while:
(seen on 88.0a1 (2021-03-08) (64-bit), trying to update to 2021-03-12)

1. Help > About TB
2. Update

Actual
- partial update downloads successfully, then restart TB to update
- Upon restart, shows "updating" - but going back to "Help > About TB", will always be back on the old version and re-download the *full* update.
- Iow, partial update (few megabytes) is no longer working for me

Expected
- successful partial update without re-updating with full update
Bug: Not all contacts from Google CardDAV provider are correctly synced
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-03-13 13:30:54+00:00
Resolved: 2021-03-14 21:33:52+00:00

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

Steps to reproduce:

I added Google CardDAV provider to the address book.


Actual results:

I have at least one contact that has an email in Google Contacts, but in the TB address book this contact has with an empty email field.


Expected results:

All Google CardDAV contact info should be synced with TB.
Bug: messages.getAttachmentFile needs to inform the File object of the content type
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-03-13 13:44:39+00:00
Resolved: 2021-03-15 09:44:10+00:00

I've been trying out bug 1550960 on latest central, and I hit an issue when loading images:

```
        let file = await browser.messages.getAttachmentFile(
          id,
          attachment.partName
        );
        let reader = new FileReader();
        attachment.url = await new Promise((resolve) => {
          reader.onload = (e) => {
            resolve(e.target.result);
          };
          reader.readAsDataURL(file);
        });
```

In this case, the data url returned always starts with `data:application/octet-stream;base64,...`.

If I try and change the content type in the url, then it still fails to load.

The solution is to tell the created `File` object about the content type, so that it can get everything right.
Bug: PEP plugin disables Open PGP in Thunderbird
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-03-13 15:00:48+00:00
Resolved: 2021-03-15 10:07:16+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

I installed PEP plugin https://pep.software/thunderbird/ for Thunderbird. 


Actual results:

OpenPGP in Thunderbird got turned off. mail.openpgp.enable set to false in config editor. 


Expected results:

OpenPGP should have worked normal as before, parallel to PEP so that I can encrypt mails for users which use OpenPGP and for users that use PEP as well. But I could only encrypt/decrypt mails for/from users who used PEP.
Bug: cannot select, attach or send attachments
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-03-13 15:38:08+00:00
Resolved: 2021-04-15 18:56:30+00:00

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.72 Safari/537.36

Steps to reproduce:

Create e-mail, select "attach" - nothing happens
Drag a file to an out-going e-mail - nothing happens
Respond to an e-mail with an attachment -  send fails, archive fails


Actual results:

see above


Expected results:

pretty obvious
Bug: Problem with receiving certain emails after install of 78.8.1
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-03-13 16:14:24+00:00
Resolved: 2021-03-28 21:18:43+00:00

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

Steps to reproduce:

 There was a automatic update installed and it was yesterday 3/11/2021 of the 78.8.1 and now I have email problems. I am not well versed in computers so I hope I explained what happened well.


Actual results:

Now I am having trouble receiving some emails and they are sent back to sender as not deliverable. 


Expected results:

I should not have any problems receiving all emails sent to me like when I had the last version update automaticly installed in Feb. 2021 (78.8.0)  Thank you for your time.
Bug: Dark theme - Account Settings > Server Settings > Advanced  > Inbox for different account - list appears blank
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-03-13 17:06:48+00:00
Resolved: 2021-04-22 12:06:23+00:00

Windows OS TB version 78.8.0
This was also tested running Thunderbird in 'Safe Mode' with same results.

TB default Dark theme
Account Settings > Server Settings for pop account
click on 'Advanced' button
Select: 'Inbox for different account'
Where you would choose eg: 'Global Inbox (Local Folders)' the pop up list appears blank.
When you hover over a point a faint blue list appears, but only if you hover specifically for each line.
The list should be in black font and display fully.

It also occurs in other themes:
Default - a theme with the operating system colour scheme
A downloaded test darktype of theme - 'Doctor who Van Gogh TARDIS'

This does Not occur in:
TB default Light theme.
A downloaded test light type of theme - 'Mystery of Stonehenge by MaDonna'


Test for High Contrasts sees the opposite effect :
Set computer to use 'High contrast black' 
pop up list has black background with clear list in white font. - so OK

Set computer to use 'High Contrast White'
Note : if Thunderbird is still using black theme, then it retains this but buttons etc are modified colour - you would expect user to not use a black theme - however the pop up list is white and blank - hover over shows clear item white text on purple background, but again only if you specifically hover over a point where you would expect list to be.