av9ash/GitBugs huggingface dataset:
Bug: Performance regression - Threaded view is slow to load
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2024-02-20 18:34:25+00:00
Resolved: 2024-02-26 18:25:02+00:00

When selected a collapsed thread in the message list the threaded view takes up to 3 seconds to load, even with just 2 or 3 messages without attachments.

Using MozRegression I identified this to be the commit range when this issue first appeared.

- Last good revision: 35817d3faea5c30525e45b6aa8eb6ecb042bb977
- First bad revision: 81c7b19049f1fed003d43368b3006cb6dbd461d2
- Pushlog:
https://hg.mozilla.org/comm-central/pushloghtml?fromchange=35817d3faea5c30525e45b6aa8eb6ecb042bb977&tochange=81c7b19049f1fed003d43368b3006cb6dbd461d2

And this should be the m-c range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1b24ea8c2e7e02f00bd61e8cd672da76b16c42a6&tochange=d6732fe2041a1e6da2c6d9d7d02ca4e327319c91
Bug: Creating a tag with a number as name in general settings throws an error.
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-02-20 21:16:19+00:00
Resolved: 2024-04-10 21:29:27+00:00

Use UI to create a tag with name 2. If this name is not allowed, there should be an error message.

Uncaught DOMException: Element.querySelector: 'richlistitem[value=2]' is not a valid selector
    addTagCallback chrome://messenger/content/preferences/general.js:2929
    onOKNewTag chrome://messenger/content/newTagDialog.js:90
    _fireButtonEvent chrome://global/content/elements/dialog.js:515
    _doButtonCommand chrome://global/content/elements/dialog.js:494
    _handleButtonCommand chrome://global/content/elements/dialog.js:488
2 general.js:2929
    addTagCallback chrome://messenger/content/preferences/general.js:2929
    onOKNewTag chrome://messenger/content/newTagDialog.js:90
    _fireButtonEvent chrome://global/content/elements/dialog.js:515
    _doButtonCommand chrome://global/content/elements/dialog.js:494
    _handleButtonCommand chrome://global/content/elements/dialog.js:488
Bug: about:3pane browsers can be in the wrong `docShellIsActive` state
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-02-20 22:36:34+00:00
Resolved: 2024-02-21 10:32:40+00:00

The 3 pane tab has multiple browser elements. Switching tabs sets the `docShellIsActive` property of the current browser. This can lead to a browser having the wrong value for the property and behaving slowly.

The multi-message browser is always set inactive, because it's never the current browser for this circumstance.
Bug: Intermittent comm/mail/base/test/browser/browser_getMessages*.js | waiting for vsync to be disabled
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2024-02-20 23:48:03+00:00
Resolved: 2024-07-01 06:23:11+00:00

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

---
```

```
Bug: Intermittent comm/mail/base/test/browser/browser_mailContext.js | Row element should no longer be attached - false == true
Status: RESOLVED
Priority: P5
Resolution: DUPLICATE
Created: 2024-02-20 23:48:47+00:00
Resolved: 2024-02-21 10:33:58+00:00

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

---
```

```
Bug: Density changes are misbehaving when resizing the message list
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2024-02-21 01:11:19+00:00
Resolved: 2024-02-22 16:20:52+00:00

steps to reproduce:
 - change densities randomly continuously

expected behaviour:
 - resizing should behave like it does in beta(123), 3 potential sizes and all padding would remain correct

actual behaviour:
- chaos.
Bug: Remove unused private variables in accountHub.js and email.mjs to fix ES lint issues.
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2024-02-21 12:57:06+00:00
Resolved: 2024-02-28 15:17:36+00:00

There are some unused private variables in accountHub.js and email.mjs that are causing ES linting issues c-c builds.
Bug: (apply) Default column display/order for account does not change
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-02-21 13:29:03+00:00
Resolved: 2024-06-23 01:45:36+00:00

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

Steps to reproduce:

1. Shuffle the columns and set new columns in one folder (e.g. Inbox of an account)
2. Apply settings to the folder and subfolders of an account
3. Make a new folder


Actual results:

The folder displays the standard columns in the default order


Expected results:

The messages are displayed with the newly set folder order.

If this is intended, an option to permanently change default ordering would be sufficient.
Bug: missing MIME or UTF8 encoding in To address (when using IDN email)
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-02-21 18:53:11+00:00
Resolved: 2024-02-22 10:03:42+00:00

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

Steps to reproduce:

I did send an eMail to an eMail address with an internationalzised domain name (IDN).


Actual results:

Some provider reject eMails with non-ASCII characters in the domain part of an eMail address, unless they are encoded.


Expected results:

The To: address of an eMail should be encoded, when it contains non-ASCII-characters, according to RFC 2047. Thunderbird does not use any encoding for the To: address (but it does for the subject or the body).

Here are two line from a test email:

Subject: =?UTF-8?Q?offene-g=c3=a4rten?=
To: test@offene-gärten.de

The Subject was encoded, the To address is not.

Attached is a typical error message from a german provider (when forwarding an email with an IDN to a web.de address):
Bug: Gmail stopped working in 115.8.0
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-02-21 20:30:28+00:00
Resolved: 2024-02-25 02:06:59+00:00

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

Steps to reproduce:

Get Messages on a Gmail account.


Actual results:

Status bar says:

Gmail: Host contacted, sending login information...

It keeps saying that until a new message appears for a different account. The Gmail never gets downloaded. This bug appeared today, immediately after I upgraded from 115.7.0 to 115.8.0. I know that my Gmail account is working fine, as the emails are coming into my phone. Also, Get Messages on many other email accounts are working fine in 115.8.0. Only Gmail is failing.


Expected results:

It should get Gmail messages. It did yesterday with 115.7.0...and for a long, long time before that. I don't recollect that it has ever failed before. This certainly seems to be a 115.8.0 bug.
Bug: Error in the functioning of subfolders of the Templates folder after editing a template inside a subfolder
Status: UNCONFIRMED
Priority: --
Created: 2024-02-22 03:12:14+00:00
Resolved: 2024-02-22 13:01:08+00:00

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

Steps to reproduce:

Create subfolder with any name in Templates folder. Example: Subtemp
Create template in Templates/Subtemp folder.
Open created template. Edit template. Save template.
The result is reproduced on version 115.7.0 on Windows and Linux versions


Actual results:

Icon subfolder - change to Icon folder Templates. Cant delete subfolder. In filesystem - file contain 2 version template (old and edited).
Bug: Menu key does not invoke context menu
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-02-22 07:34:15+00:00
Resolved: 2024-03-07 21:32:06+00:00

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

Steps to reproduce:

Thunderbird 115.6.0 (64-Bit) on Linux Mint

System:    Kernel: 5.4.0-170-generic x86_64 bits: 64 compiler: gcc v: 9.4.0 
           Desktop: Cinnamon 5.2.7 wm: muffin dm: LightDM Distro: Linux Mint 20.3 Una 
           base: Ubuntu 20.04 focal 

1. select message in message list
2. press menu key




Actual results:

outcome: nothing happens


Expected results:

expected outcome: context menu should open
Bug: Content of emails in folders are incorrect
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2024-02-22 10:14:43+00:00
Resolved: 2024-05-21 09:56:05+00:00

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

Steps to reproduce:

Infrequently, I find messages in my folders that have the incorrect content in. The actual content is missing and contain the content of another message in the same folder. This remains that way unless I delete the account and create the account again so that the emails and folders are refreshed from the server.



Expected results:

Content should be the same as received from the server originally.
Bug: Collapsed mail folders do not show correct size
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-02-22 11:05:25+00:00
Resolved: 2024-02-22 11:10:50+00:00

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

Steps to reproduce:

Use an email account with multiple folders/labels, some of which are nested.
Select and click on a twistie  '>' to open a folder tree to 'V' and note what happens in the "Total Message Count" and "Folder size" columns. 


Actual results:

When a twistie is clicked open to show a tree, the message counts correctly reflect the number of messages in each folder, and the message size reflects the size of the contents of each folder.  That's as expected, I suggest.
Now close the twistie '>'.  The message count now includes ALL the messages in subfolders.  I believe this is the correct and expected function.  However, the  message size still ONLY includes messages in the top level folder. 



Expected results:

With twisties closed (folders collapsed), top level folders should show, as well as the total message count (which they do) the total underlying message size (which they do not).  This omission makes it impossible to scan the list of top level mail folders to determine where space is being used.
Bug: Crash in [@ getMethodFromRelativeList]  macOS 14
Status: NEW
Priority: --
Created: 2024-02-22 11:12:31+00:00
Resolved: 2024-03-05 22:02:52+00:00

Crash report: https://crash-stats.mozilla.org/report/index/1110d2df-e5b4-4be2-9653-5ad880240221

Reason: ```EXC_BAD_ACCESS / KERN_MEMORY_ERROR```

Top 10 frames of crashing thread:
```
0  libobjc.A.dylib  getMethodFromRelativeList  
1  libobjc.A.dylib  lookUpImpOrForward  
2  libobjc.A.dylib  _objc_msgSend_stret_uncached  
3  WindowManagement  -[WMStage initWithCoder:]  
4  Foundation  _decodeObject  
5  Foundation  __44-[NSXPCDecoder _decodeArrayOfObjectsForKey:]_block_invoke  
6  Foundation  _NSXPCSerializationIterateArrayObject  
7  Foundation  -[NSXPCDecoder _decodeArrayOfObjectsForKey:]  
8  Foundation  -[NSDictionary initWithCoder:]  
9  Foundation  _decodeObject  
```
bp-a71d1dc2-6836-4afb-b0a8-6c6bf0240221  beta 124
Bug: Startup Crash in [@ mozilla::detail::InvalidArrayIndex_CRASH | nsTArray_Impl<T>::ElementAt | nsTArray_Impl<T>::operator[] | nsMsgGroupView::OnHdrDeleted] macOS
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-02-22 11:16:36+00:00
Resolved: 2024-03-06 17:52:31+00:00

Crash report: https://crash-stats.mozilla.org/report/index/8b9170b7-eca1-4de3-9458-051ad0240206 beta 124

Reason: ```SIGSEGV / SEGV_MAPERR```

Top 10 frames of crashing thread:
```
0  thunderbird-bin  MOZ_Crash  mfbt/Assertions.h:301
0  thunderbird-bin  mozilla::detail::InvalidArrayIndex_CRASH  mfbt/Assertions.cpp:50
1  libxul.so  nsTArray_Impl<unsigned int, nsTArrayInfallibleAllocator>::ElementAt  xpcom/ds/nsTArray.h:1208
1  libxul.so  nsTArray_Impl<unsigned int, nsTArrayInfallibleAllocator>::operator[]  xpcom/ds/nsTArray.h:1245
1  libxul.so  nsMsgGroupView::OnHdrDeleted  mailnews/base/src/nsMsgGroupView.cpp
2  libxul.so  nsMsgDatabase::NotifyHdrDeletedAll  mailnews/db/msgdb/src/nsMsgDatabase.cpp:756
3  libxul.so  nsMsgDatabase::DeleteHeader  mailnews/db/msgdb/src/nsMsgDatabase.cpp:1775
4  libxul.so  nsMsgDatabase::DeleteMessages  mailnews/db/msgdb/src/nsMsgDatabase.cpp:1724
5  libxul.so  nsImapMailFolder::UpdateImapMailboxInfo  mailnews/imap/src/nsImapMailFolder.cpp:2610
6  libxul.so    mailnews/imap/src/nsSyncRunnableHelpers.cpp:122
```
beta 123 bp-40490313-2260-4076-9032-8eb110240131
Bug: onNewMailReceived mail extension event creates messagelist for Inbox for messages that have been moved to another folder
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2024-02-22 14:35:01+00:00
Resolved: 2024-04-01 08:16:20+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36

Steps to reproduce:

I have an IMAP account with a thunderbird filter set up to move mail based on the To: field. This moves messages from /Inbox to /Inbox2. 
What I see is onNewMailReceived, the message list shows the message as coming into /Inbox. Additionally if I then try to get the message details from the ID using message.get(), it has all its information missing and a unix epoch timestamp. See below for an example.

If I set /Inbox2 properties to "When getting new messages for this account, always check this folder" I get a messageList for the /Inbox2, which great, but I ALSO still get onNewMailReceived fired for /Inbox with the same message details.

I see a similar bug here with regards to POP but Im using IMAP. Noting incase its related.
https://bugzilla.mozilla.org/show_bug.cgi?id=1836511

Here are the objects of the troublesome message.

```messageList
{
  "id": null,
  "messages": [
    {
      "id": 1,
      "date": "2024-02-22T14:13:21.000Z",
      "author": "me@example.com",
      "recipients": [
        "me@example.com"
      ],
      "ccList": [],
      "bccList": [],
      "subject": "Test",
      "read": false,
      "new": true,
      "headersOnly": false,
      "flagged": false,
      "junk": false,
      "junkScore": 0,
      "headerMessageId": "8669c7d2-0149-424c-a6bb-8b91ae76f5f5@gmail.com",
      "size": 10266,
      "tags": [],
      "external": false,
      "folder": {
        "accountId": "account1",
        "name": "Inbox",
        "path": "/INBOX",
        "type": "inbox"
      }
    }
  ]
}
```

```messages.get(1)
{
  "id": 1,
  "date": "1970-01-01T00:00:00.000Z",
  "author": "",
  "recipients": [],
  "ccList": [],
  "bccList": [],
  "subject": "",
  "read": false,
  "new": false,
  "headersOnly": false,
  "flagged": false,
  "junk": false,
  "junkScore": 0,
  "headerMessageId": "",
  "size": 0,
  "tags": [],
  "external": false,
  "folder": {
    "accountId": "account1",
    "name": "Inbox",
    "path": "/INBOX",
    "type": "inbox"
  }
}
```


Actual results:

Messages moved by a filter are shown in onNewMailReceived's message list with the original folder and not its destination unless "When getting new messages for this account, always check this folder" is set in which case onNewMailReceived triggers for both


Expected results:

As per the onNewMailReceived API docs:
"Fired when a new message is received, and has been through junk classification and message filters." 
I expect the message list to show the message as a new mail in its destination folder after all filters have been applied. I'm not sure whether this means only firing if "When getting new messages for this account, always check this folder" is set or not but certainly it shouldnt send events for both.
Bug: Links don't open
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2024-02-22 16:25:35+00:00
Resolved: 2024-02-26 00:01:08+00:00

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

Steps to reproduce:

click on a link in received email


Actual results:

Links in received emails do not open default web browser (Firefox)


Expected results:

link should have opened in browser -- this has worked in previous versions
Bug: Folder Pane Header - Show Total Size - Not displaying true size - not the same as mbox size in profile.
Status: NEW
Priority: --
Created: 2024-02-22 17:36:55+00:00
Resolved: 2024-10-14 02:11:18+00:00

Windows OS
beta 124.0b1

Folder Pane Header option 'Show Folder Size' enabled.

**Actual Results**
The folder size is a total size of all emails currently displaying in Message List assuming all threads displayed.
The folder size is not displaying the true size of the folder - aka the mbox file size which still contains marked as deleted emails.
The folder 'Properties' shows same size which is also not the true size of file.

This is new in Supernova 115* and a complete change from what occurs in previous versions eg: 102.15.1

**Expected Results**
The folder size in Folder Pane and in a folder 'Properties' should display the true size of the mbox file.

**Benefit of seeing correct size data:**
When you compact a folder, you see the change in folder size immediately in the Folder Pane.

This informs you of the following:
True size of folder
the compact on folder took place as a reduction in size visually occurred.
Alerts you if a problem is occuring.

Current problem - you have to open the profile view to see what is really the folder size. 
Users have no idea whether compacting occurred, or whether compacting was successful or failed or whether they need to compact in the first place.
Support Forum reports are discovering issues with file size eg: Trash says it's 30MB in Folder Pane, but Trash mbox file is 600MB in profile.
The folder size as displayed in Folder Pane and in folder Properties is misleading and incorrect. 

Showing the real and correct size in Folder Pane is important and informative.
Bug: messages filter dialog - buttons not showing in correct place
Status: NEW
Priority: --
Created: 2024-02-22 21:29:18+00:00
Resolved: 2024-06-07 12:57:21+00:00

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

Steps to reproduce:

new filter
apply : impossible


Actual results:

2 buttons in one place


Expected results:

2 buttons but one near the other not on it
Bug: Security-Relevant: Message subject of GPG encrypted mail is wrongly assigned to different message, breaks confidentiality
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-02-23 09:06:09+00:00
Resolved: 2024-02-23 12:49:13+00:00

Steps to reproduce:

* Create three mails:
  * Subject: Mail No. 1, Content: Content No. 1, No encryption, no signature
  * Subject: Mail No. 2, Content: Content No. 2, No encryption, no signature
  * Subject: Mail No. 3, Content: Content No. 3, Subject encrypted, encrypted, signed
* Repair folder to reset the decryption-state of Mail 3.
* Select Mail No. 2 and press "a" quickly two times to archive Mail No. 2 and Mail No. 3
* (Sometimes requires) Change Folder and go back to folder with Mail No. 1


Actual results:

Subject of Mail No. 1 is now "Mail No. 3", and e.g. replying will also use this subject. This persists with restarts, only repairing the folder fixes this.


Expected results:

Subject should remain "Mail No. 1"
Bug: Add-ons debugging page still shows the old Thunderbird logo
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-02-23 09:58:26+00:00
Resolved: 2024-02-28 05:43:29+00:00

See the item outlined in red on my screenshot.

I've also noted that the tab's title shows "Debugging / Runtime - this-firefox"; it sounds like we might want to remove the Firefox reference? I'm not super familiar with our addons support so feel free to ignore this last comment if it doesn't make sense.
Bug: Intermittent ld.lld: error: undefined hidden symbol: already_AddRefed<nsISupports> mozCreateComponent<nsISupports>()
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2024-02-23 12:36:03+00:00
Resolved: 2024-02-26 07:07:37+00:00

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

---
```
Upstream changes in 1770944 landed in 14952f872b77 remove support for `jsm` key in `components.conf`, breaking legacy (non-esModule) declarations
```
Bug: Subject line is all �
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-02-23 14:47:38+00:00
Resolved: 2024-02-26 14:57:31+00:00

Steps to reproduce:

Receive email (see attached page source)


Actual results:

Subject line shows as:
`���������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������`


Expected results:

Subject line should be: 
`Weekly market update + Growing the value of bp`
Bug: Unchecking "Show all headers" in Message Header Settings closes dialog
Status: NEW
Priority: --
Created: 2024-02-23 16:36:35+00:00
Resolved: 2024-10-30 15:36:38+00:00

Steps to reproduce:

1. Open the Message Header Settings in the email view using the "More" button in the email view.
2. Check and uncheck various options (The Message Header Settings dialog will remain open)
3. Check then Uncheck the "Show all headers" option


Actual results:

When unchecking the "Show all Headers" option, the dialog will close.


Expected results:

The dialog should remain open like it does when changing any of the other options.
Bug: The OK button is not visually displayed if you use Russian in File-Offline-Download/Sync Now-Ok
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-02-23 17:01:51+00:00
Resolved: 2024-04-11 11:08:16+00:00

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

Steps to reproduce:

File-Offline-Download/Sync Now-Ok


Actual results:

Thunderbird Version 115.8.0 (64-bit)
The OK button is not visually displayed if you use Russian in File-Offline-Download/Sync now-Ok. If you use the Tab key, the Ok button is highlighted (part of the blue border is visible), but it is not displayed.


Expected results:

It is not possible to press the OK button because it is not displayed.