av9ash/GitBugs huggingface dataset:
Bug: Command handler doesn't handle file:// URLs leading to problems opening .ics or .eml files via the XDG Desktop Entry Specification using %u
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-02-12 22:40:16+00:00
Resolved: 2023-11-15 07:10:10+00:00

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

Steps to reproduce:

In `/usr/share/applications/thunderbird.desktop`, the `Exec` directive says:

`Exec=/usr/lib/thunderbird/thunderbird %u`

The "XDG Desktop Entry Specification" states that "%u" is "A single URL. Local files may either be passed as file: URLs or as file path. ".

However, Thunderbird does not seem to support "file: URLs" paths.

In fact, I use mimeo as my file opener.

When I configure it to open .ics files with Thunderbird, it calls:

```
❯ mimeo --debug 2022507AR0704.ics 
[...]
DEBUG: /usr/lib/thunderbird/thunderbird file:///home/[MYUSERNAME]/Downloads/[MYFILE].ics
```

and Thunderbird returns the error:

```
JavaScript error: resource:///modules/MessengerContentHandler.jsm, line 508: NS_ERROR_FILE_NOT_FOUND: Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsICommandLine.resolveFile]
```

So I think the "%u" in the desktop file should be "%f", which is described by the specification as "A single file name (including the path)", which is what Thunderbird seems to support.


Actual results:

See above


Expected results:

See above
Bug: Opening .eml files - delete/junk etc. buttons should be disabled
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-02-13 01:39:15+00:00
Resolved: 2023-05-15 18:37:28+00:00

Opening a message from file (.eml), on trunk everything is enabled.

junk, delete, archive should be disabled
In the More menu: Tag, Mark as Read should be hidden.

Not sure what regressed it (may be a mix of things). On 102 delete/junk are disabled (but archive enabled).
Bug: Intermittent comm/mail/test/browser/composition/browser_attachmentReminder.js | Test timed out
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2023-02-13 01:57:26+00:00
Resolved: 2023-03-01 03:38:52+00:00

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

---
```

```
Bug: Intermittent comm/mail/test/browser/composition/browser_draftIdentity.js (finished) |  application timed out after 370 seconds with no output
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2023-02-13 02:01:40+00:00
Resolved: 2023-03-01 04:52:52+00:00

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

---
```

```
Bug: [TB 110.0b4] URL / Link colour lack contrast in dark theme
Status: NEW
Priority: --
Created: 2023-02-13 07:03:26+00:00
Resolved: 2023-07-24 05:31:11+00:00

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

Steps to reproduce:

Using TB 110.0b4 in dark mode on Windows 11.
When replying to emails containing links, unable to read the links clearly


Actual results:

The contrast colour for the links in dark theme do not make them legible


Expected results:

The colour contrast for a link should be configurable or a set to a default colour that makes it legible in dark mode.
Bug: commonDialog.xhtml is missing colors.css
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-02-13 11:08:51+00:00
Resolved: 2023-02-17 20:11:29+00:00

The commonDialog base does not have colors.css loaded, which leads to the primary button having no background color. This is likely a regression from the recent selection color pruning.
Bug: Spelling check not correct when using templates
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-02-13 12:18:21+00:00
Resolved: 2023-08-08 00:57:03+00:00

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

Steps to reproduce:

1. Start writing a new mail in a different language than English.
2. Select the corresponding spelling from the Spelling menu selection according to the language you are using.
3. Save this e-mail as a template.
4. Double click the template to start writing a new mail based on that template.


Actual results:

Despite the correct language will be selected in the Spelling menu, all words will be marked with red wavy underlines indicating spelling errors because the window will perform a spelling check for English language.


Expected results:

The correct language should be applied and the entire contents of the e-mail should not be marked will red underlines as spelling errors.
Bug: Intermittent comm/mail/components/extensions/test/browser/browser_ext_clickHandler.js | Test timed out
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2023-02-13 22:22:48+00:00
Resolved: 2023-03-13 06:10:07+00:00

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

---
```

```
Bug: Intermittent comm/mail/test/browser/composition/browser_sendFormat.js | TypeError: can't access property "headerValue", get_about_message().currentHeaderData['content-type'] is undefined
Status: RESOLVED
Priority: P5
Resolution: WORKSFORME
Created: 2023-02-13 22:23:58+00:00
Resolved: 2024-08-30 00:07:38+00:00

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

---
```

```
Bug: Intermittent comm/mail/test/browser/attachment/browser_attachmentMenus.js | TypeError: can't access property \"isExternalAttachment\", currentAttachments[0] is undefined at onShowSaveAttachmentMenuSingle
Status: RESOLVED
Priority: P5
Resolution: WORKSFORME
Created: 2023-02-13 22:27:32+00:00
Resolved: 2024-08-30 00:07:03+00:00

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

---
```

```
Bug: Various dialog sizing issues with flexbox emulation
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-02-14 02:28:52+00:00
Resolved: 2023-09-05 12:53:37+00:00

Trying to tackle all the regressions in our dialogs.
Some are tricky since they're a tangle of XUL mess and we should really rebuild them all in HTML, or just drop most of them for subdialogs.

For now, let's try to fix them as much as possible.
Bug: cert override (for self signed certificates) dialog doesn't come up in many cases
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-02-14 02:56:53+00:00
Resolved: 2023-05-26 16:55:56+00:00

The dialog to add a certificate exception doesn't pop up when it should.
It should pop up for user action "Get messages" - and used to do so in 102. 
I did some testing and the bug on trunk is quite peculiar. It's aggregated by not having a "Get messages" toolbar button, but that's not the full story.

There are - unfortunately - a few different code paths exercised to get the messages. 
Mainly two ways though: account node context menu Get messages, and File | Get New Messages for <account>.

102:
* pop3: context ok, file menu ok
* imap: context NOT ok, file menu ok

2023-01-13 daily:
* pop3 context ok, file menu ok (but there is some intermittence with both)
* imap context NOT ok, file menu ok

current daily:
* pop3 context NOT ok, file menu NOT ok
* imap context NOT ok, file menu ok

So in summary, POP3 accounts regressed. But IMAP context menu was also broken since long, and atm. the context menu is more exposed than it used to.
Bug: can't log in with 0auth to Outlook server with TB 102.7.1 or 102.7.2
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2023-02-14 03:41:00+00:00
Resolved: 2023-10-29 18:21:08+00:00

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

Steps to reproduce:

1.upgraded from earlier version to 102. (fedora 36 and 37 package 102.7.1 or 102.7.2 -- tried both)
2. start Thunderbird
3. press button to fetch mail from outlook.office365.com with employer's configuration using OAuth2.


Actual results:

1. filled in password at prompt.
2. error message was displayed: "Need admin approval
Mozilla Thunderbird
needs permission to access resources in your organization that only an admin can grant. Please ask an admin to grant permission to this app before you can use it."


Expected results:

After my entering password, a new prompt should appear for two-factor auth (in this case, a text or phone call),  After that, the usual list of new email messages should appear.
Bug: Junk filter moving mail from folders to junk folder
Status: UNCONFIRMED
Priority: --
Created: 2023-02-14 04:31:50+00:00
Resolved: 2023-12-17 03:51:10+00:00

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

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

Steps to reproduce:

1) Created a message filter to move candidate messages from the inbox to the designated folder
2) Enable junk mail controls on the email account in question
3) When new mail arrived, the message filter created in step #1 ran and moved a candidate message to the designated folder (expected behavior)
4) Then, I noticed the message was *then* moved from the designated folder to the junk folder


Actual results:

Mail in a folder, not the inbox, is getting moved to the junk folder.


Expected results:

Mail being moved to a folder should NOT be identified as junk, since those messages are no longer in the inbox.
Bug: Move to "Inbox" Again didn't move the message to Inbox in Thunderbird 111.0a1
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-02-14 06:52:07+00:00
Resolved: 2023-04-24 19:51:47+00:00

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

Steps to reproduce:

I used Thunderbird 111.0a1 (2022-1-20) to (2022-2-13) on Wayland in Plasma 5.26.5 in a Fedora 37 KDE Plasma installation. I right-clicked on emails in the folders of an IMAP account or Local Folders. I clicked on Move to "Inbox" Again (or other folders instead of "Inbox") in the context menu, where Inbox is a local folder. I clicked on Message in the menu bar then Move to "Inbox" Again (or other folders).


Actual results:

Selecting Move to "Inbox" Again in the context menus or Message menu in the menu bar didn't move the email to Inbox in Local Folders or whatever other folder was shown instead of "Inbox" in Thunderbird 111.0a1 (2022-1-20) to (2022-2-13). The messages remained in the folders they were in. This problem didn't happen with 111.0a1 (2023-1-18) and earlier. I guess the problem is related to the interface changes which were merged then as described at https://thunderbird.topicbox.com/groups/daily/T7df1556699d655bb/please-read-thunderbird-supernova-alpha-release I waited until February 14 to report this problem as requested on that page.

Selecting Move To > Local Folders > Inbox in the context menu or Message menu moved the emails normally. The problem is specific to the Move to "Inbox" Again items.


Expected results:

Selecting Move to "Inbox" Again in the context menus or Message menu in the menu bar should have moved the email to Inbox in Local Folders or whatever other folder was shown instead of "Inbox" in Thunderbird 111.0a1.
Bug: Right-clicking on emails in message lists didn't show their context menus unless they had been left-clicked first in Thunderbird 111.0a1
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-02-14 07:19:36+00:00
Resolved: 2023-04-24 19:51:28+00:00

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

Steps to reproduce:

I used Thunderbird 111.0a1 (2022-1-20) to (2022-2-13) on Wayland in Plasma 5.26.5 in a Fedora 37 KDE Plasma installation. I right-clicked on emails in the folders of an IMAP account or Local Folders without having left-clicked on them or otherwise selected them first. I left-clicked on emails in lists and then right-clicked on them. I right-clicked on different emails than the ones I left-clicked on right before then.


Actual results:

Right-clicking on emails in lists didn't show their context menus when they hadn't been selected first. Right-clicking on emails in lists showed their context menus when they had been left-clicked first in Thunderbird 111.0a1. Right-clicking on emails other than the one previously selected by left-clicking on it showed a context menu that when selected acted on the previously selected email instead of the email under the cursor. This problem didn't happen with 111.0a1 (2023-1-18) and earlier. I guess the problem is related to the interface changes which were merged 2023-1-19 https://hg.mozilla.org/comm-central/pushloghtml?fromchange=76f62fd3a78092592457e19dbc6e59f87c4f084d&tochange=5abcc1359eb7d4122f958a823e29b43de5f60b2e as described at https://thunderbird.topicbox.com/groups/daily/T7df1556699d655bb/please-read-thunderbird-supernova-alpha-release I waited until February 14 to report this problem as requested on that page.


Expected results:

Right-clicking on emails in lists should have shown their context menus when they hadn't been selected first by left-clicking on them. Right-clicking on emails other than the one previously selected by left-clicking on it should have shown a context menu that when selected acted on the email under the cursor.
Bug: Select All didn't select the emails in the current folder, but selected all the emails in the following folders in Thunderbird 111.0a1
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2023-02-14 07:50:51+00:00
Resolved: 2023-02-16 23:39:55+00:00

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

Steps to reproduce:

I used Thunderbird 111.0a1 (2022-1-20) to (2022-2-13) on Wayland in Plasma 5.26.5 in a Fedora 37 KDE Plasma installation. I pressed ctrl+a to select all emails in the folders of an IMAP account or Local Folders. Alternatively, I selected Edit menu in the menu bar then Select > All. Then, I selected different folders.


Actual results:

Using Select All didn't select any of the emails in the current folder immediately. Left-clicking on an email in the first folder after selecting all showed all emails as being selected. Using Select All again removed the selection from all the emails in the folder. After using Select All, all the emails were selected in the following folders that I changed to. All the emails remained selected in those folders after left-clicking on emails which used to remove the selection of all emails. This problem didn't happen with 111.0a1 (2023-1-18) and earlier. I guess the problem is related to the interface changes which were merged 2023-1-19 https://hg.mozilla.org/comm-central/pushloghtml?fromchange=76f62fd3a78092592457e19dbc6e59f87c4f084d&tochange=5abcc1359eb7d4122f958a823e29b43de5f60b2e as described at https://thunderbird.topicbox.com/groups/daily/T7df1556699d655bb/please-read-thunderbird-supernova-alpha-release I waited until February 14 to report this problem as requested on that page.


Expected results:

Using Select All should have selected all the emails in the current folder immediately and not after left-clicking on one email in it. The emails in the following folders I went to shouldn't have all been selected, and clicking on one of those emails should've removed the selection of all of them.
Bug: Filelink preference "Offer to share for files larger than" wrongly reset at every restart
Status: UNCONFIRMED
Priority: --
Created: 2023-02-14 08:40:00+00:00
Resolved: 2024-03-02 17:01:21+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:98.0) Gecko/20100101 Firefox/98.01

Steps to reproduce:

Add a filelink add-on and storage service to TB, select the related preference "offer to share for larger files" in the settings->composition->attachments. Everything works as expected. Restart TB, and the preference is "un"selected. 
There is no such preference in the user.js file, in other words the unexpected change is not triggered by a setting in user.js.


Actual results:

no filelink offered when a large attachment is added to a new email


Expected results:

obvious from the description above
Bug: Intermittent comm/mail/components/extensions/test/browser/browser_ext_menus_replace_menu.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2023-02-14 09:37:16+00:00
Resolved: 2024-03-25 06:41:03+00:00

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

---
```

```
Bug: Intermittent comm/mail/test/browser/content-policy/browser_jsContentPolicy.js | JS should be turned on in content. - "undefined" == true - "got (void 0), expected true (operator ==)"
Status: RESOLVED
Priority: P5
Resolution: WORKSFORME
Created: 2023-02-14 09:39:01+00:00
Resolved: 2024-08-30 00:07:28+00:00

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

---
```

```
Bug: Intermittent comm/mail/test/browser/tabmail/browser_customize.js | Drag data transfer was undefined - "undefined" == true
Status: RESOLVED
Priority: P5
Resolution: WORKSFORME
Created: 2023-02-14 09:42:18+00:00
Resolved: 2024-08-30 00:07:19+00:00

**Filed by:** martin [at] humanoids.be
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=405563103&repo=comm-central
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/fO9icP4cQPyX24whF-PVow/runs/0/artifacts/public/logs/live_backing.log

---
```
Not sure it's worth looking into this unless it happens a lot, since this functionality should be removed eventually.
```
Bug: Only the first part of the first image attachment is visible
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2023-02-14 09:51:28+00:00
Resolved: 2023-07-18 06:47:24+00:00

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

Steps to reproduce:

Open Thunderbird to read emails


Actual results:

In emails with attachments such as images, PDF files, the attachments are truncated, so that only the first part of the first image is visible and accessible and the pdf file is unreadable. The image attached shows an email which actually has two images attached.


Expected results:

All attachments should be readable/accessible. I have tested this with a virgin copy of Windows 10 and a virgin copy of Thunderbird 102.7.2.
Bug: Email notification displays old messages
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2023-02-14 14:26:00+00:00
Resolved: 2023-10-07 18:05:21+00:00

Steps to reproduce:

I use Thunderbird in the background. There was no particular user action in this case.


Actual results:

Using verion 102.7.1 (64-bit), OS is Manjaro with 5.15.91-1-MANJARO which uses Dunst for notifications. Thunderbird runs usually in the background. A sporadic behavior is that the notifications for "new" emails show emails that were received last night or some hours ago. Also, the notifications do not arrive in aggregate, but one email at a time.

 This appears to be a regression that was introduced at some point since I clearly recall this wasn't so in the past.


Expected results:

As a user I expect that all notifications for email that I haven't read and that are newly received by Thunderbird should be shown in one notification when Thunderbird starts. From that point on I would expect Thunderbird to notify my only about newly received messages.
Bug: Port bug 1815370: about:preferences "Default Font" menu gets unexpected text-selections inside of & around it, if you click and hold to open the menu
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-02-14 15:09:46+00:00
Resolved: 2023-03-27 03:47:01+00:00

This bug will fix some drag and drop issues in the calendar, the fact you can select all kinds of things in the main window currently and probably other stuff I haven't even found yet.
Bug: Import colors.css and variables.css in dialogs that needs them
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-02-14 15:23:21+00:00
Resolved: 2023-03-06 08:08:22+00:00

We need to add colors.css and variables.css to dialogs that use themeableDialog.css and don't import them through other files.
Bug: Since update to 102.7.2 thunderbird was very slow and often stopped working for a time. Downgrading to 102.6.1 fixed the problem.
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-02-14 16:17:46+00:00
Resolved: 2023-02-14 23:07:06+00:00

Steps to reproduce:

I recently updated Thunderbird to version 102.7.2. (Downgrading to 102.6.1 fixes the problem.)


Actual results:

Thunderbird got stuck often for quite a while. It most often happened when loading mails, but there seemed other occasions, too. When looking in the task-manager, it was not actually Thunderbird that took up a lot of CPU at those times but my antivirus (Avira). This never happened with old versions.


Expected results:

102.7.2 should be at least as good (and fast) as the older version.
Bug: Default Settings for New Feeds apply only on root, not in any others subfolders
Status: UNCONFIRMED
Priority: --
Created: 2023-02-14 16:21:12+00:00
Resolved: 2023-02-14 16:21:12+00:00

Steps to reproduce:

1) Change the Default Settings for New Feeds "Check for for new articles" to 1 day.
2) Create a folder/subfolder (at any depth)
3) Right-click on the new folder and, in the contextual menu, select "Subscribe..." to add a new feed



Actual results:

The "Check for for new articles" setting is set to 100 min (the default installed value)


Expected results:

The "Check for for new articles" settings should be set to 1 day (the user configured one)