av9ash/GitBugs huggingface dataset:
Bug: Repair Folder command said to cause data loss, warning needed
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-05-02 02:27:56+00:00
Resolved: 2021-07-28 02:04:10+00:00

STR:

0. Don't do this unless you have a backup copy of your emails, and you probably don't.
1. Select an email folder in Tbird.
2. Open the context menu.
3. Select Properties, which will open the General Information tab.
4. Click (or, rather, don't click) the Repair Folder button.

Actual result:

According to a commenter in another topic (bug 1707428 comment 4), this causes loss of date-time information in some cases. This was an explanation offered about a problem I reported in that thread.

I don't know the Tbird version for when my problem occurred, but it was recent and it is now 78.8.1 (64-bit).

For my problem: Fedora 33 at the time; 34 now; kept evergreen.

For the commenter's platform: I don't know the Tbird version or platform information or experience timing.

Expected result:

Either don't delete information about an email or warn us about the risk as part of confirming that we wish to attempt a repair anyway.

On whether to warn, see bug 1099275; this issue qualifies for a warning.
Bug: Thunderbird does not report background color appropriately when dark theme is used
Status: UNCONFIRMED
Priority: --
Created: 2021-05-02 12:58:41+00:00
Resolved: 2022-01-14 06:09:27+00:00

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

Steps to reproduce:

In KDE settings, setup the "Breeze dark" theme:
1. Global theme: "Brise sombre" (translation may be like "Breeze dark")
2. Plasma style: "Breeze sombre"
3. Colors: "Brise sombre"
4. Icons: "Breeze sombre"

You may need to restart Thunderbird to ensure changes are taken into account.

Then, you should see that when writting emails, your text is white and your background is dark. This is great, except that some plugins like "LatexIt" need to obtain the text color to appropriately add LaTeX images.


Actual results:

When using a plugin like "LatexIt", the text color that is reported is the color of the "themed" version, not the one of the final, sent email. Therefore, when writing an email via LatexIt, the math text is written in white on dark theme: the problem is that when sending the email, the background will be turned back into white, making any equation unreadiable.

You can find some screenshots here: https://github.com/protz/LatexIt/issues/61#issuecomment-821852988


Expected results:

I'd expect LatexIt to obtain the color of the text in the final email.

Ideally, one could imagine two ways to obtain the current color, one with the color in the final email, and one with the color in the current (themed) window.

I'd also love to be able to disable temporarily the theme on a single textarea (with a right-click for instance) to properly render this kind of emails, but I'm not sure if Thunderbird can do it or if a report must be done to KDE instead.
Bug: under Wayland, Join Chat dialog often flickers and is unresponsive to typing
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2021-05-03 09:02:34+00:00
Resolved: 2021-05-05 11:52:03+00:00

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

Steps to reproduce:

Fedora 34 KDE Spin defaults to Wayland. So I ran 
  $ export MOZ_ENABLE_WAYLAND=1
  $ gtk-launch mozilla-thunderbird

and Thunderbird ran as a Wayland client of kwin_wayland, not X11!

Things work pretty well, until I went to my Chat tab where I had a few IRC channels open, and clicked [Join Chat] and started typing a Channel name.


Actual results:

Much of the time, the Join Chat dialog window that appears flickers, showing the text underneath a few times. When this happens, the dialog is thereafter extremely slow to respond to typing and/or continues to flicker and show the text underneath.


Expected results:

The dialog should always display flicker-free on top and be responsive to keystrokes.

I don't know how to reliably trigger the problem. It happened several times when I first tried to join some more IRC channels, but reproducing for this bug it was fine 10x in a row just now and then acted up.
Bug: With Exchange server and ExQuilla addon: Send immediately may result in some attachments missing in forwarded message
Status: VERIFIED
Priority: --
Resolution: MOVED
Created: 2021-05-03 13:40:36+00:00
Resolved: 2021-06-02 17:15:53+00:00

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

Steps to reproduce:

I received an email with 3 PDF files attached (between 500k - 6MB each). I wanted to forward the email to another address, so I pressed forward and basically right away pressed the send button. 

I'm not sure if it matters but this was on an Exchange account that I connect to using the plugin ExQuilla. 


Actual results:

When I pressed the forward button, the mail message opened and the attachments were still being loaded into the message. By the time I pressed the send button, clearly, not all attachments were loaded yet and, as I feared, the recipient only received one of the 3 attachments. 


Expected results:

IMO, something like this must not be allowed to happen. TB should see that the original message comes with a certain number of attachments and, when forwarding, the send button must not be activated until the message is complete.
Bug: Creating a calendar event from an ICS attachment makes it impossible to view the original e-mail content
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-05-03 13:46:02+00:00
Resolved: 2021-05-06 09:46:35+00:00

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

Steps to reproduce:

- Receive and view an e-mail with an ICS event attached
- In the blue bar above the message content, where it says "This message contains an event", click "Add" to add an event to a calendar
- Read another message, then read the invitation E-Mail again



Actual results:

The message has a "This message contains an event that has already been processed" bar, and original message content is *no longer visible*. This happens after closing/reopening the message at least once. The message view under the From/Subject/To headers is simply an empty white box.

In my case the message body includes important information I will need for the appointment, e.g. waiting number, list of documents to bring, etc. The only way I found to still see the content was using "View Source", but this requires parsing HTML in my head. The content does not appear in the calendar event "Description" field.


Expected results:

The message should be visible as it was before.
Bug: Intermittent comm/mail/test/browser/folder-display/browser_rightClickMiddleClickMessages.js and/or browser_selection.js | Test timed out -
Status: RESOLVED
Priority: P5
Resolution: WORKSFORME
Created: 2021-05-03 23:36:13+00:00
Resolved: 2024-08-30 00:06:58+00:00

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

---
```
Breaking this off from bug 1707152. It's failed a few times since I last had a go at it.```
Bug: Perma comm/mail/test/browser/tabmail/browser_dragndrop.js | Test timed out -
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2021-05-03 23:37:19+00:00
Resolved: 2021-05-27 12:16:45+00:00

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

---
```
Breaking this off from 1707152. It's not worked since the native context menus landed.```
Bug: Mac Big Sur "Save as..." does nothing
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-05-04 00:56:27+00:00
Resolved: 2021-11-10 19:07:17+00:00

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

Steps to reproduce:

Open email message
Click "Save As..." on the More Menu


Actual results:

nothing


Expected results:

A file save dialog should open
Bug: deadlock when authenticating for send and receive
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-05-04 03:24:21+00:00
Resolved: 2021-05-08 13:27:20+00:00

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

Steps to reproduce:

0) When Thunderbird launches, it usually shows a password dialog to authenticate with an IMAP server and receive new mail.  In this case, Thunderbird has not been launched yet.
1) In Firefox, I click on a mailto link, which launches Thunderbird and opens a Write window.  However, the password dialog to authenticate with an IMAP server does not appear.
2) When I click Send, Thunderbird tries to authenticate for sending.


Actual results:

Thunderbird shows a blank modal sheet and becomes unresponsive.


Expected results:

I believe when Thunderbird launches, the IMAP authentication dialog should appear first since it is modal.  When clicking a mailto link, the Write window can be brought forward after dismissing the authentication dialog.
Bug: GenericSendMessage FAILED: NotReadableError: Could not read file because it is not UTF-8 encoded
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-05-04 05:48:47+00:00
Resolved: 2021-05-04 06:44:08+00:00

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

Steps to reproduce:

After an (automatic) update to 89.0b2 
tried to answer a mail...



Actual results:

Same effect as in Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1706956
but not on MacOS rather on Windows 10 (two independent installations)!

When I try to answer to a an existing message and send it a popup is shown for a split of a second and nothing happens.

I got this error:
GenericSendMessage FAILED: NotReadableError: Could not read file(C:\Users\philipp\AppData\Local\Temp\nsemail.eml) because it is not UTF-8 encoded MsgComposeCommands.js:4861
    CompleteGenericSendMessage chrome://messenger/content/messengercompose/MsgComposeCommands.js:4861
    AsyncFunctionThrow self-hosted:699
    (Async: async)
    GenericSendMessage chrome://messenger/content/messengercompose/MsgComposeCommands.js:4789
    SendMessage chrome://messenger/content/messengercompose/MsgComposeCommands.js:5198
    doCommand chrome://messenger/content/messengercompose/MsgComposeCommands.js:995
    doCommand chrome://messenger/content/messengercompose/MsgComposeCommands.js:1191
    goDoCommand chrome://global/content/globalOverlay.js:101
    oncommand chrome://messenger/content/messengercompose/messengercompose.xhtml:1
Bug: Help | troubleshooting yields Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIStringBundle.GetStringFromName]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://messenger/content/about-support/aboutSupport.js
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-05-04 06:16:33+00:00
Resolved: 2021-05-11 02:26:12+00:00

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

I just encountered this with 89.0b2 on Mac after a crash.  Troubleshooting is missing the contents of the labels column

 [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIStringBundle.GetStringFromName]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://messenger/content/about-support/aboutSupport.js :: application :: line 259"  data: no] aboutSupport.js:259:27
    application chrome://messenger/content/about-support/aboutSupport.js:259
    onload chrome://messenger/content/about-support/aboutSupport.js:57
    <anonymous> self-hosted:1225
Bug: Threads not fully working
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-05-04 06:27:36+00:00
Resolved: 2021-05-27 07:30:00+00:00

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

Steps to reproduce:

I do not know what happened, but from some time now "Threads" are working partially in my Thunderbird. Sometimes the messages are grouping in treads, but sometimes not. Including an image of an example. My version of Thunderbird is 78.10.0 (64-bit).


Actual results:

I'm including an image, where the threads are turned on, by the messages are not grouping.


Expected results:

The threads should be created properly.
Bug: Tooltip errors for chat search results
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-05-04 12:07:12+00:00
Resolved: 2021-12-15 22:37:37+00:00

### Steps to reproduce

1. Search for a chat message using the search input.
2. Open search result in chat.
3. Hover over the search richlistitem on the left hand side with a pointer to show the tooltip.

### Result

Tooltip with missing images and empty text pops up and the console error:

```
JavaScript error: chrome://chat/content/chat-tooltip.js, line 388: TypeError: can't access property "isChat", aConv is undefined
```

### Expect

Probably no tooltip.

## Origin

I think the problem comes from the fact that the `id=searchResultConv` element borrows the `chat-imconv-richlistitem` element structure, but doesn't call any of its methods to set the properties that are assumed by the tooltip (in this case, `aConv` specifically).

Specifically, I suspect this line:

https://searchfox.org/comm-central/rev/6dbfd83437bab124d39332c768a5f55a36e7a196/chat/content/chat-tooltip.js#105

## Fix?

Currently, the `searchResultConv` item has an `is-search-result` attribute, which could probably be used for a quick fix. But that attribute is already a hack (which I added recently when I changed the icons) so maybe this element could do with its own class as a much cleaner solution.
Bug: Accounts folders ordering  has changed
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-05-04 14:23:30+00:00
Resolved: 2021-05-05 06:25:51+00:00

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

Steps to reproduce:

The ordering of account folders has changed by itself with the upgrade to 89.

In the past RSS feeds were shown as the last account folder in the Folders box, after the Local folders. Now the order is reversed.

This is especially problematic when one is subscribed to thousands of news feeds, that usually have no real importance in comparison to local kept emails in the Local folders. The current behaviour of Thunderbird is even more problematic that it does not keep the Feeds account collapsed, but expands it automatically, so that one has to manually collapse it several times a day, and one needs to scroll down for several pages to get to the Local folders.


Actual results:

The current ordering of folders now:
- Remote folders (IMAP accounts,...)
- Feeds (RSS,...)
- Local folders



Expected results:

The most logical ordering of account folders should be like it was in the past: 
- Remote folders (IMAP accounts,...)
- Local folders
- Feeds (RSS,...)
Bug: ExQuilla add on Issue
Status: VERIFIED
Priority: --
Resolution: INVALID
Created: 2021-05-04 15:24:19+00:00
Resolved: 2023-01-29 00:36:11+00:00

ExQuilla add on best for exchange account Ubuntu 


but sir in windows   We could not find an auto discover site for your email address, either because it does not exist, or because the name and password failed. This may be because your server does not support Exchange Web Services (EWS). If your server does not support EWS, then ExQuilla will not work for you. If you believe this to be in error, try manually entering the EWS URL.  



This message show and not sync Exchange account but in Ubuntu they work very Well
Bug: Sending a reply doesn't work if reply contains a quote of the original mail and "spell checking before sending" is selected.
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-05-04 17:25:39+00:00
Resolved: 2021-05-21 13:44:03+00:00

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

Steps to reproduce:

cuando se contesta un correo no se puede enviar


Actual results:

Al pulsar ENVIAR la respuesta hace como una ventana muy rápida y se queda sin enviar


Expected results:

Se debería de enviar sin problemas
Bug: "About Thunderbird" popup uses light theme when using dark theme.
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-05-04 23:46:29+00:00
Resolved: 2021-08-12 17:14:40+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.7113.93 Safari/537.36

Steps to reproduce:

On mac, while using the Thunderbird dark theme (and the system is using dark theme too, fyi), click the "About Thunderbird" button.




Actual results:

Popup is using light theme.


Expected results:

Popup should use dark theme, like the rest of thunderbird.
Bug: Send button disabled after reply-all to more than 15 recipients (mail.compose.warn_public_recipients.threshold)
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-05-05 01:32:43+00:00
Resolved: 2022-03-23 03:36:40+00:00

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

Steps to reproduce:

Replied to a group email with 16 (well curated) recipients that use a cc list for mailing comments.


Actual results:

Thunderbird displayed a "this has more than 15 recipientes, do you want to make it a BCC?" warning (as is appropriate).  However, when I selected the option that indicated that was fine with me and I wanted to keep them as CCs, the send button stayed greyed out and I could not send the message.

Eventually I managed to find the advanced option and just increase the threshold before sending.


Expected results:

Since this is a warning, it should have warned me, but allowed me to proceed if I selected the "yes, this is ok with me" option without having to dig into the advanced options to work around it.
Bug: Ellipsis (…) missing for some menu labels (actions which require further input to be performed), especially in Open PGP key manager
Status: NEW
Priority: --
Created: 2021-05-05 03:44:07+00:00
Resolved: 2024-02-27 09:27:54+00:00

STR:

1. In Tbird, open menus and select the commands stated in step 4.
2. If the command here says "(untested)", maybe you should not select the command but instead determine whether a dialog or similar would follow if selected.
3. If the command is dimmed, select something so that the command is available.
4. The commands:
File > Save As > Template
Edit > Folder Properties
Edit > Account Settings
Edit > Preferences
Go > Recently Closed Tabs > Account Settings (untested)
Go > Recently Closed Tabs > Preferences (untested)
Message > Forward
Message > Forward As > Inline
Message > Forward As > Attachment
Message > Edit As New Message
Message > Archive (untested)
Tools > Address Book
Tools > Saved Files (untested)
Tools > Add-ons
Tools > Add-ons > Add-ons Manager > Recent Updates > Manage Your Updates > gear icon > Debug Add-ons
Tools > Add-ons > Add-ons Manager > Recent Updates > Manage Your Updates > gear icon > Manage Extension Shortcuts
Tools > Activity Manager
Tools > Message Filters
Tools > Run Filters on Folder (untested)
Tools > Run Filters on Message (untested)
Tools > Run Junk Mail Controls on Folder (untested)
Tools > OpenPGP Key Manager
Tools > Developer Tools > Developer Toolbox (untested)
Tools > Developer Tools > Debug Add-ons
Tools > Developer Tools > Content Frame Debugger
Tools > Developer Tools > Error Console

Actual result:

No ellipsis follows the command name.

I did not examine all dimmed commands, so I may have missed some that need ellipses.

Expected result: An ellipsis character after the command name where a dialog or similar would result from invoking the command. This assures the user of harmlessness from invoking the command alone. See also bug 1707434.

Additional info: Fedora 34 Linux, kept evergreen, including Tbird 78.8.1 (64-bit), without add-ons.
Bug: Message header buttons won't wrap or iconize if Thunderbird window has less width than needed to display them all, causing message body display truncation on the right
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-05-05 07:03:15+00:00
Resolved: 2021-05-05 19:36:44+00:00

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

Steps to reproduce:

Configure Thunderbird Interface in French (fr), with TB sized on half screen
Configuration: Ubuntu 21.04 (fr-FR interface) and TB 78.8.1 (I have this problem since Ubuntu 20.10).


Actual results:

Long lines in received messages (text or HTML) doesn't wrap correctly (see the screen capture). This problem doesn't appear with en-US interface.
Bug: Composition header shrinks after adding new recipient [caused by addon]
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-05-05 13:30:24+00:00
Resolved: 2021-05-05 15:00:59+00:00

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

Steps to reproduce:

New Message
Click CC to open CC list
Add to either recipient or CC list


Actual results:

The viewport that contains the TO & CC recipients shrinks and obscures the field for the CC recipients, requiring the composition window header to be resized manually.


Expected results:

The viewport containing both TO & CC recipients should always be the minimum height of the number of text fields currently active - if CC recipients, the viewport should be the height of the TO field + any padding + margins. If active, the viewport should be the height of both fields + padding and margins applicable. If BCC is also active, the height rule should apply for the BCC field as well.
Bug: 89.0b2 - can't send any message which includes BCC field
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-05-05 18:18:35+00:00
Resolved: 2021-05-06 04:51:25+00:00

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

Steps to reproduce:

Create new message.
Add "To:" address and (different) BCC: address. 
Message body remains empty (except for signature, which has been the same for many years). 
Attempt to send message. 


Actual results:

A small window flashes up and disappears (too quickly to see what it is) and the New Message window stays open. Message does not send (and won't send)
If I remove BBC field then message sends normally


Expected results:

Mail should have been sent

Problem also in 89.0b1, but probably not in 88.x Problem also occurs in troubleshooting mode. 

Error console shows:  
Prompter: internal dialogs not available in this context. Falling back to window prompt.
 GenericSendMessage FAILED: NotReadableError: Could not read file(C:\Users\<user>\AppData\Local\Temp\nsemail-5.eml) because it is not UTF-8 encoded
Bug: Browsing chat logs clears the topic
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-05-05 18:38:46+00:00
Resolved: 2022-08-24 09:21:19+00:00

STR:
- View a conversation with logs and a topic
- Select some logs to view
- Exit the log viewer

Expected result:
The topic stays displayed below the conversation name.

Actual result:
The topic is cleared when viewing the log and not restored when closing the viewer. Previous behavior didn't even clear the topic in the first place.

Based on mozregression I think the regression is from https://hg.mozilla.org/comm-central/rev/9c30d915b033eac597a413f39840285c5b889661
Bug: All emails disappeared after upgrade to version 78
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-05-05 19:31:58+00:00
Resolved: 2021-05-06 07:12:43+00:00

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

Steps to reproduce:

Went to bed. Woke up in the morning and all emails (Mozilla) were gone. Even in the subfolders. None were missing on local storage


Actual results:

See above