av9ash/GitBugs huggingface dataset:
Bug: Crash in [@ OOM | large | XPCConvert::JSData2Native] trying to send attachment
Status: NEW
Priority: --
Created: 2024-05-17 09:54:56+00:00
Resolved: 2024-07-09 04:02:12+00:00

#9 crash for 115.8.0. Prior to that it was #26 or lower.  Regression of bug 1873023?   If not that, then [one of these 115.8.0 uplifts?](https://bugzilla.mozilla.org/buglist.cgi?bug_id=1872239%2C1871343%2C1874898%2C1862387%2C1874895%2C1850266%2C1865620%2C1869557%2C1863957%2C1873487%2C1873101%2C1874504%2C1870641%2C1877232%2C1873655%2C1869122%2C1876733%2C1874646%2C1725127%2C1875358%2C1872799%2C1873023%2C1849650&list_id=17036854)

Crash report: https://crash-stats.mozilla.org/report/index/f66146be-4c87-4b4e-8f60-9cd1f0240321

MOZ_CRASH Reason: ```out of memory: 0x000000001912EFFD bytes requested```

Top 10 frames:
```
0  mozglue.dll  MOZ_Crash(char const*, int, char const*)  mfbt/Assertions.h:264
0  mozglue.dll  mozalloc_abort(char const* const)  memory/mozalloc/mozalloc_abort.cpp:26
1  mozglue.dll  mozalloc_handle_oom(unsigned int)  memory/mozalloc/mozalloc_oom.cpp:51
2  mozglue.dll  moz_xmalloc(unsigned int)  memory/mozalloc/mozalloc.cpp:54
3  xul.dll  XPCConvert::JSData2Native(JSContext*, void*, JS::Handle<JS::Value>, nsXPTType...  js/xpconnect/src/XPCConvert.cpp:603
4  xul.dll  CallMethodHelper::ConvertIndependentParam(unsigned char)  js/xpconnect/src/XPCWrappedNative.cpp:1549
4  xul.dll  CallMethodHelper::ConvertIndependentParams(bool*)  js/xpconnect/src/XPCWrappedNative.cpp:1475
4  xul.dll  CallMethodHelper::Call()  js/xpconnect/src/XPCWrappedNative.cpp:1172
4  xul.dll  XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)  js/xpconnect/src/XPCWrappedNative.cpp:1126
5  xul.dll  XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*)  js/xpconnect/src/XPCWrappedNativeJSOps.cpp:966
```

Other examples:
* bp-6767cb57-e893-4e09-b614-18d850240304
* bp-86a0c8a7-2d21-4341-b30d-200d90240402
* bp-b274e890-fc6a-4c9a-ac60-e54c00240515  trying to send large attachment
* bp-4925a903-1449-41a9-ad6b-be2c90240425  non-Windows crash with different crash signature
Bug: "Empty Trash on Exit" on a POP3 account expands the account in the folder tree
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-05-17 10:08:57+00:00
Resolved: 2024-09-26 08:03:22+00:00

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

Steps to reproduce:

I logged my issue on the Thunderbird support forum in December 2023 as this only appeared after I updated to SuperNova.

Wayne Mery replied to the support question and said:

'If you see this with 115.11.0, filing a bug report would be fine. In your report please provide the URL to this support question.' 

I am currently on 115.11.0 (64-bit), and the issues still exist.

The URL for the support details is:
https://support.mozilla.org/en-US/questions/1433988?utm_campaign=questions-reply&utm_source=notification&utm_medium=email#answer-1653279


Actual results:

See the Support question detailed previously for full details and screenshots, as per Wayne Mery.


Expected results:

See the Support question detailed previously for full details and screenshots, as per Wayne Mery.
Bug: Multiple spaces in subject line concatenated to single spaces in display view
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-05-17 14:30:32+00:00
Resolved: 2024-05-19 08:51:49+00:00

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

Steps to reproduce:

Sent an email from Outlook where the  SUBJECT  line was :

Let's see  how this  behaves  around double  spaces  this time

(2 spaces before 'how', 2 spaces after 'this', 2 spaces before 'around', 2 spaces after 'double', 2 spaces after 'spaces'


Actual results:

When displaying the message, Mozilla does not show the extra spaces - everything is reduced to one space, both in  "Message List"  view and when actually opening the message.

However, when clicking REPLY, we can see in the original message that those spaces do exist.

This issue was picked up because a user was sending a password phrase in the  SUBJECT  line of the message, with, sometimes, two spaces instead of one between words.  The recipient was replicating what he was seeing but the password phrase would not work.


Expected results:

Thunderbird should not  "massage"  anything when displaying emails, whether in the MESSAGE BODY or in the MESSAGE SUBJECT.

Thunderbird should reproduce exactly what it receives, including multiple spaces otherwise it is effectively not a 100% correct email system.
Bug: Empty unread messages from 1970 (!)
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-05-18 00:51:42+00:00
Resolved: 2024-05-18 13:11:55+00:00

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

Steps to reproduce:

I am unsure what conditions trigger the bug, but I encounter it fairly regularly and it seems that the bug has been occurring for 11 (eleven) years (as I will detail).


Actual results:

Unopenable emails appear in the inbox and they are dated . . 1970.


Expected results:

Obviously, not that.

There is an _ancient_ bug report here: <https://bugzilla.mozilla.org/show_bug.cgi?id=851462>. The report is closed. The closer invited re-opening 'with attaching sufficient data for problem analysis'. Yet, I see no way of re-opening the bug. Hence this new bug report. Nor am I clear what information is sought. So, (@WADA:World Anti-bad-Duping Agency - for such was the closer), what is needed? I can add immediately: Windows 10 Pro - 22H2 (2009: 19045); Thunderbird 115.10.1; IMAP (and only IMAP) accounts. 

Please note that this bug makes Thunderbird look silly and annoys the user.
Bug: Unnecessary modal dialog boxes
Status: UNCONFIRMED
Priority: --
Created: 2024-05-18 12:32:15+00:00
Resolved: 2024-08-24 20:14:14+00:00

Steps to reproduce:

Just use TB with a lot of folders and sooner or later a background operation will try to do a maintenance task, find the task locked for some reason or another, and throw a modal dialog box to tell you that the task you didn't know was running can't do the task you didn't ask it to do right now and demand approval for it to not do that task now and get to it later.  This is not a request, OK?


Actual results:

Thunderbird regularly throws modal dialog boxes with a single option to inform users of something they're not remotely engaged in and that do not matter at all, except to get rid of the stupid modal dialog box and get back to work. Or it throws errors with a false choice, retry or cancel.  Obviously retry later when the network is working again and why bother me, the user, with your dumb problems?  


Expected results:

Maybe, if logs are enabled, log the error plus details just in case the user wants to investigate why some background maintenance task wasn't happening, if they notice.

As a rule, modal dialog boxes are satan's spawn.  They are only necessary when something really bad has happened that will result in loss of data or prevent the user from doing their work.  Examples might include having the hard disk fail or the network go out during send or (though this is not a modal dialog and should be) the messages not background sending from the outbox after 3 attempts or 30 minutes or something.  Or when the user has to make a choice between two bad options and that choice actually makes a difference.

That a folder could not be background compacted because another operation is in progress is NOT something I, or any other user, needs to know at all let alone interrupt our work and demand that we acknowledge this passive aggressive complaint by one worker thread that another worker thread is jamming their work flow.  

If your network happens to drop, Bender help you, every message in the outbox has to seek affirmation that you know it tried to send it and failed, please forgive the program.  Nothing you can do about it, just want to make you, the user, as miserable as the program feels right now not being connected.  It will try later.  Why not just have a "connected to IMAP" indicator and quietly cue transient failures for later retry?  

The "retry or cancel" dialogs are just as stupid, just keep retrying in the background, the network will return.  Sure TB gets very confused by network changes and you usually have to restart to get it to work again.  Maybe that would be useful: "ONE message that your network changed causing TB to lose connectivity, restart to reconnect when you can, all send operations have failed.  Fetch operations, for some reason, manage to find the new server.  OK?"
Bug: Input fields have no border in Addressbook
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-05-19 08:49:55+00:00
Resolved: 2024-07-09 00:30:38+00:00

This variable makes the border color transparent on macOS in the address book edit contact panel: https://searchfox.org/comm-central/source/mail/themes/osx/mail/messenger.css#16
Bug: In message composition window top row of keys sometimes do not work
Status: UNCONFIRMED
Priority: --
Created: 2024-05-19 21:11:29+00:00
Resolved: 2024-05-21 17:21:08+00:00

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

Steps to reproduce:

Composing message.


Actual results:

 Suddenly, top row of keys on keyboard do not work (neither digits not punctuation marks).

If I SAVE the message (I may have to do that 2 or 3 times) then those keys work.


Expected results:

All keys should work.

I realize that this might seem to be possibly be an O/S or keyboard problem, except that nothing like this happens in many other keyboard-based apps I use.
Bug: Comboboxes report incorrect setsize
Status: NEW
Priority: --
Created: 2024-05-20 09:01:38+00:00
Resolved: 2024-09-26 14:00:20+00:00

Steps to reproduce:
1. Get into the calendar's New Event dialog
2. Change the Repeat combobox's value (e.g. Every Weekday)
3. Launch the Accerciser accessibility inspector and examine the attributes of the selected menu item, either via the UI or via the iPython Console (`acc.getAttributes()`)

Expected results: The setsize attribute would reflect the total number of items in the combobox (e.g. 8)

Actual results: The setsize attribute is 1.

Impact: Orca (with its child-position feature enabled) says "Every Weekday. 4 of 1" instead of "Every Weekday. 4 of 8".

Note: Since posinset and setsize are platform-agnostic properties originating from ARIA and not something specific to Linux, this bug could impact Windows and/or Mac *if* those screen readers consume the attribute rather than calculating the correct value.

Here's the output from the iPython console:

```
['explicit-name:true',
 'display:flex',
 'margin-bottom:0px',
 'posinset:4', <-- GOOD
 'margin-top:0px',
 'tag:menuitem',
 'id:repeat-weekday-menuitem',
 'setsize:1', <-- WRONG
 'text-indent:0px',
 'margin-right:4px',
 'text-align:start',
 'margin-left:4px']
```
Bug: TypeError: lazy.l10n.getValueSync is not a function
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-05-20 12:46:33+00:00
Resolved: 2024-05-21 22:51:31+00:00

I'm getting `TypeError: lazy.l10n.getValueSync is not a function imCore.sys.mjs:210:23`

Looks like it should be `formatValueSync`
Bug: Changing sort in in threaded unified folder does not set secondary sort
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-05-20 13:40:22+00:00
Resolved: 2024-06-04 08:41:48+00:00

__Steps to reproduce:__
1. Create a new saved search covering at least two folders. View should be threaded and sorted by date, all threads collapsed.
2. Sort by subject.
3. Sort by correspondents.
4. Sort by unthreaded.
5. Sort by subject.
6. Sort by correspondents.
7. Sort by threaded.

__Expected result:__
After step 3, messages with the same correspondent should be sorted by subject.

__Actual result:__
After step 3, messages with the same correspondent are sorted by order received, which is the default secondary sort type. After step 7 those messages are sorted by subject, but changing the sort again doesn't set the secondary sort.
Bug: Zoom video conference meeting links are non-functional
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-05-20 23:23:13+00:00
Resolved: 2024-05-21 04:15:50+00:00

🔵  It is common practice in commercial & educational scenarios to issue Zoom meeting invites by e-mail.
🔵  However, some e-mail clients omit the <href> attribute during message composition.
🔵  When this occurs, it is not possible for the recipient to join a meeting by clicking the link.
🔵  Only Thunderbird users are affected -- these links work correctly in Apple & Microsoft mail clients.
_____
In broken invites, message source is structured like this:

    <div class="default-style"> Join Zoom Meeting <br>
		https://us01web.zoom.us/j/12345678901?pwd=1234aBcDeFgHiJkLmNoPqRsTuVwXyZ.1
    </div>
_____
In working invites, message source is structured like this:

     <div class=3D"default-style"> Join Zoom Meeting <br>
		<a class=3D"moz-txt-link-freetext" href=3D"https://us01web.zoom.us/j/12345678901?pwd=1234aBcDeFgHiJkLmNoPqRsTuVwXyZ.1">
		https://us01web.zoom.us/j/12345678901?pwd=1234aBcDeFgHiJkLmNoPqRsTuVwXyZ.1</a>
     </div>

This bug report is an intentional duplicate of bug 680352 [2011] & bug 920560 [2013] with a different title to cover the large number of Zoom users who are affected by this issue [ > 300 million per day ].
Bug: Thunderbird shows incomplete email addresses when replying/forwarding or “edit as new” for the first time
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-05-21 10:21:06+00:00
Resolved: 2024-05-21 12:49:02+00:00

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

Steps to reproduce:

Open Thunderbird and try to reply to a message.


Actual results:

The sender is displayed incompletely.

If you repeat this step, the sender is complete. To see the error again, Thunderbird must be restarted.


Expected results:

The sender is displayed completely.
Bug: Immediately clicking on “Send Later” deletes the corrected email address
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-05-21 10:33:20+00:00
Resolved: 2024-10-12 18:53:57+00:00

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

Steps to reproduce:

1. Insert incorrect e-mail address
2. correct e-mail address (with copy & paste)
3. click on “Send Later” IMMEDIATELY


Actual results:

 Old, incorrect e-mail address remains (only visible in "Drafts" or after sending).


Expected results:

 New, correct e-mail address appears
Bug: Migrating from UI version xx to 43 failed. - exception in OutgoingServerService.sys.mjs :: _keyToServer
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-05-21 11:31:10+00:00
Resolved: 2024-07-04 19:39:06+00:00

Started an old profile. Got
console.error: "Migrating from UI version 34 to 43 failed. Error message was: [Exception... \"Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPrefBranch.getCharPref]\"  nsresult: \"0x8000ffff (NS_ERROR_UNEXPECTED)\"  location: \"JS frame :: resource:///modules/OutgoingServerService.sys.mjs :: _keyToServer :: line 247\"  data: no] -- Will reattempt on next start."

This seems to be half-intentional - https://searchfox.org/comm-central/rev/9a8e81d16a3de5e97406ac2f769a85a6bf5a87b0/mailnews/compose/src/OutgoingServerService.sys.mjs#244 - but wrong. It will hold up all further migrations.
It should be built just to filter out such cases, not throw.
Bug: moving email to archive subfolder doesn't add this subfolder to recent folders (MRU)
Status: NEW
Priority: --
Created: 2024-05-21 13:06:25+00:00
Resolved: 2024-10-15 01:39:27+00:00

### Steps to reproduce
1. create a subfolder `remember_me` in Archive
2. drag+drop email from Inbox to `Archive/remember_me`
3. select another email in Inbox
4. right-click context-menu > move to > recent

### actual results
`remember_me` does not show up in this recent folder list.
(However, it does show up in `right-click context menu > move to "remember_me" again`, which tells us that it makes sense to also remember Archive subfolders.)

### expected results
`remember_me` should be included in recent folder list.

### reproducible: always
Reproduced in TB 115 and TB 128.0a1 (2024-05-17) (64-bit) @Win10-64bit.
Bug: displayed folder is hidden in foldertree due to miscalculation of bounding rects?
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2024-05-21 13:18:30+00:00
Resolved: 2025-01-26 14:53:04+00:00

use legacy code or webextention code to set the displayed folder in a mailtab. If the folder is at the top, the folder tree is not scrolled enough and the folder name in the tree is hidden under the new message button.

Something like this solves for my screen resolution:

```
  ensureFolderIsVisible: function (win, folder) {
    let folderTree = win.folderTree;
    let folderPane = win.folderPane;
    let fPane = folderTree.parentElement;
    let folderPaneRect = fPane.getBoundingClientRect();
    let folderRow = folderPane.getRowForFolder(folder);
    let folderRowRect = folderRow.getBoundingClientRect();
//    console.log("in scroll", folderTree, folderPane, fPane, folderRowRect, folderPaneRect);
    fPane.scrollTop = folderRowRect.y-50;

  },
Bug: T'bird message filter engine does not work well: is buggy?
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2024-05-21 14:02:53+00:00
Resolved: 2024-05-22 14:23:52+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.6.1 Safari/605.1.15

Steps to reproduce:

I am running Tbird on a 2013 iMac running MacOS 10.15.7. I have it set to filter incoming messages and put them into folders in Local Folders. It does that intermittently or not at all for some filters, and regularly for others. 
The "Run Filters on Message" and "Run Filters on Folder" commands in the Menu bar "Tools" do not work at all, but then when I run a selected filter manually from within the Message Filters window on a specific message or messages, that filter does work. 
Also, I cannot select more than one filter at a time.
Bug: [meta] Thunderbird bugs which affect/inconvenience 3rd parties (email recipients, servers, etc.)
Status: NEW
Priority: --
Created: 2024-05-22 04:04:49+00:00
Resolved: 2024-10-23 16:19:02+00:00

## purpose
It might be helpful to collect and thereby highlight reports of bugs affecting third parties (i.e. not just the Thunderbird user alone), because:
1. they can negatively affect Thunderbird's standing and reputation
2. they may be embarrassing for the Thunderbird user vis-à-vis other people (boss, family, etc.)

## scope
In order to be eligible for this list, the bug must somehow affect/involve a 3rd party – this is the common denominator of the bugs here.
The aggrieved party may be either the 3rd party or the TB user.

## bug list

| bug #  | **effect on 3rd party: server** |
| ------------- | ------------- |
| bug 1508030 | Thunderbird accidentally triggers DoS attacks |
| bug 1641882 | infinite loop when talking to server ? |
| bug 216739 | continuous server pinging |
| bug 1862111 | too many failed login attempts, IMAP account gets locked |
| bug 1903811 | DDoS-like batches of requests to RSS feeds, Thunderbird's IPs get blocked, users get banned |


| bug #  | **effect on 3rd party: email recipient** |
| ------------- | ------------- |
| bug 134256 | recipient receives multiple email duplicates from TB user |
| bug 620853 | *(same as above)* |
| bug 1180633 | TB user could accidentally embarrass/compromise sender by disclosing BCC-email-reception to others |
| bug 1784050 | TB sends MDNs disclosing the email address of the user's default identity (privacy invasion of TB user and confusing for sender) |
| bug 36482 | recipient may accidentally receive email from wrong/private address |
| bug 699681 | *(same as above)* |
| bug 382580 | *(same as above)* |
| bug 1764075 | recipient may receive email with missing attachment |
| bug 1720311 | recipient receives garbage |

 
You are very welcome to add bugs. Please include a short note how the 3rd party is involved/affected.
Bug: last message in list is not top
Status: UNCONFIRMED
Priority: --
Created: 2024-05-22 08:00:39+00:00
Resolved: 2025-02-02 17:41:50+00:00

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

Steps to reproduce:

Why, when having multiple email accounts, do I have to scroll several lines to the top every time I switch from one account's inbox to another? Why doesn't it happen automatically? Is there a setting for this? I use sorting by date, newest at the top.


Actual results:

I select the inbox list and have to scroll several lines to see the first item in the list (according to the applied sorting). It's annoying, especially when there are multiple accounts.


Expected results:

I select the inbox list, and the first message in the list (according to the applied sorting) should be visible.
Bug: compose window customize toolbar: many missing fluent strings ([fluent] Missing message in locale en-US: signing-toggle etc.)
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-05-22 10:10:51+00:00
Resolved: 2024-05-27 22:05:49+00:00

Open compose, right click to compose the toolbar. Check console, I get:

```
[fluent] Missing message in locale en-US: signing-toggle
[fluent] Missing message in locale en-US: text-action-cut
[fluent] Missing message in locale en-US: text-action-copy
[fluent] Missing message in locale en-US: text-action-paste
[fluent] Missing message in locale en-US: button-return-receipt
[fluent] Couldn't find a message: signing-toggle
[fluent] Couldn't find a message: text-action-cut
[fluent] Couldn't find a message: text-action-copy
[fluent] Couldn't find a message: text-action-paste
[fluent] Couldn't find a message: button-return-receipt
[dom/l10n] Errors during l10n mutation frame.

```
Bug: Intermittent comm/mail/components/extensions/test/browser/browser_ext_content_handler.js | Should have seen exactly one tab being updated
Status: NEW
Priority: P5
Created: 2024-05-22 11:10:58+00:00
Resolved: 2024-10-29 10:46:28+00:00

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

---
```
 comm/mail/components/extensions/test/browser/browser_ext_content_handler.js | Should have seen exactly one tab being updated - [[142,{"url":"moz-extension://dd155836-19cb-4c2b-bd9b-8289cda80f2c/handler.html#ext%2Btest%3Apayload"}],[143,{"url":"moz-extension://dd155836-19cb-4c2b-bd9b-8289cda80f2c/handler.html#ext%2Btest%3Apayload","complete":true}]]

Only the "complete" is different
```
Bug: ${UpdateChannel} not defined in NSIS installer
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-05-22 20:21:11+00:00
Resolved: 2024-05-29 12:34:42+00:00

Error when building the installer:
`6000: unknown variable/constant "{UpdateChannel}" detected, ignoring (macro:WordFindCall:3)`