av9ash/GitBugs huggingface dataset:
Bug: typing or pasting quotes in Compose Window brakes quote bar
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2022-07-19 18:45:56+00:00
Resolved: 2022-09-06 14:10:53+00:00

Steps to reproduce:

All with "[ ] edit messages in html" unchecked
- start a reply with quotes and linebrakes # Texededitor is opened
- mark all text and cut
- paste cut text from clipboard.


Actual results:

quotes view has gone and play ">" are shown.


Expected results:

quotes view as copied should be kept
Bug: Address book manager initialised at start-up unnecessarily
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2022-07-20 02:43:36+00:00
Resolved: 2022-07-24 23:21:23+00:00

There's no reason for the address book manager to be initialised during normal start-up, but currently it does, for two reasons:
- the message header "edit contact" pop-up contains an address book menu list, which needs the list of address books
- telemetry data collection happens too early

In this bug I'll fix both of these and add AddrBookManager.jsm to the list of prohibited modules in browser_startup.js to ensure it doesn't happen again.
Bug: link extension context menu is not added for References links in header pane for news messages
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2022-07-20 10:54:31+00:00
Resolved: 2025-02-08 10:56:30+00:00

Steps to reproduce:

Consider an extension that register a menu entry for the "link" context. The menu item does not appear for the "References" links in the header pane for news (NNTP) messages despite such links from user point of view are essentially the same as "mid:" links.

- Load some add-on that handles links through a context menu item, an example is provided below.
- Check that context menu appears for links in message body.
- Try some message from a news account that does not start new thread so has "References" field in the headers pane.
- Inspect context menu items for a "References" link.

`manifest.json`
```json
{
	"manifest_version": 2,
	"name": "Link Menus Test",
	"version": "0.1",
	"background": { "scripts": [ "linmen-bg.js" ] },
	"permissions": [ "menus" ]
}
```

`linmen-bg.js`
```js
"use strict";

async function linmenCreateMenu() {
	await browser.menus.removeAll();

	browser.menus.create({
		contexts: [ "link" ],
		id: "LINMEN_LINK",
		title: "Link Menu Test",
	}, function linmenOnMenusCreated() {
		const error = browser.runtime.lastError;
		if (error) {
			console.error("linmenOnMenusCreated: error: %o", error);
		}
	});
}

browser.menus.onClicked.addListener((clickData, tab) =>
	console.log("linmen.onClicked: %o", clickData, tab));
linmenCreateMenu();
```


Actual results:

No menu item appears, so add-on can not handle "References" links.

The behavior is the same for thunderbird-104.0a1.


Expected results:

- Menu item is displayed for "References" links.
- Menu handler is called as for a "mid:" link.

P.S. Actually discrepancy of behavior for "mid:" links and for "References" is greater for some reason. Click on a reference does not open new tab or window.
Bug: messages.getRaw fails on newsgroups
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-07-20 15:03:01+00:00
Resolved: 2022-11-16 18:08:33+00:00

messages.getRaw fails on newsgroup messages, throwing the following exception:

Exception { name: "NS_ERROR_XPC_JSOBJECT_HAS_NO_FUNCTION_NAMED", 
message: "JavaScript component does not have a method named: \"streamMessage\"'JavaScript component does not have a method named: \"streamMessage\"' when calling method: [nsIMsgMessageService::streamMessage]", result: 2153185328

This is thrown in the "nntp" branch of `getMimeMessage()` which calls `MsgHdrToRawMessage()`
Bug: Message compose vertical scrollbar covers inline image anchors
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2022-07-20 16:25:08+00:00
Resolved: 2023-03-21 04:25:01+00:00

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

Steps to reproduce:

Open new message compose window.
Insert large inline image (3000px wide).
Try to grab the bottom-right image anchor in order to resize the image.
As mouse cursor moves to right margin of compose window, vertical scrollbar appears making it impossible to grab bottom-right image resize anchor.



Actual results:

Right-side image anchors cannot be grabbed with the mouse for image resizing due to being covered by the vertical scrollbar of the compose window.


Expected results:

The message content should appear completely to the left of the vertical scrollbar so the scrollbar does not cover message content.
Bug: [comm-esr91] makecab toolchain failed to build for 91.12 release
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2022-07-20 18:19:25+00:00
Resolved: 2022-07-29 08:19:07+00:00

The makecab toolchain did not build. It errors out building the libz-sys dependency.

I haven't had any luck making it work even locally. The plan is to backport the version of makecab that's on comm-central to comm-esr91.

makecab is used for symbols upload and the release will block if those jobs don't run.
Bug: Status bar result message after downloading messages (e.g. "No new messages") remains until other user activity
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-07-20 22:15:27+00:00
Resolved: 2022-08-04 18:10:49+00:00

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

Steps to reproduce:

Check mail for a single account, or check mail for all accounts.


Actual results:

Status Bar shows the checking and "no new messages" messages for each account. The final message never goes away.


Expected results:

After last account is checked, final message should be cleared from status bar, thus providing an indication that all accounts have been checked.  This worked properly up to 99.11.0; it does not work in 102.0 through 102.0.3.
Bug: Intermittent comm/mail/base/test/performance/browser_preferences_usage.js | toolkit.scrollbox.verticalScrollDistance should be accessed at least 100 times. - 100 <= 72
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2022-07-21 02:33:25+00:00
Resolved: 2022-07-25 06:30:48+00:00

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

---
```
Something made this better, yay.
```
Bug: The from/to no longer appears when you are on an email
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-07-21 07:49:23+00:00
Resolved: 2022-07-21 08:18:49+00:00

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

Steps to reproduce:

Thunderbird 102.0.3
The from/to no longer appears when you are on an email


Actual results:

The from/to no longer appears when you are on an email
Bug: Move to recent causes long delay before list of recent folders is shown
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-07-21 08:29:46+00:00
Resolved: 2022-07-25 01:40:27+00:00

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

Steps to reproduce:

Move an email to 'recent' causes long delay before list of recent folders is shown.


Actual results:

Move an email to 'recent' causes long delay before list of recent folders is shown.


Expected results:

On older 9x version. Move an email to 'recent' folders is shown almost instantly.
Bug: Space bar no longer scrolls summary of multiple selected messages
Status: UNCONFIRMED
Priority: --
Created: 2022-07-21 10:22:50+00:00
Resolved: 2023-09-18 13:07:07+00:00

Steps to reproduce:

Select a collapsed thread, or multiple messages by other means, such that the resulting summary of the selected messages does not fit in the preview pane.


Actual results:

Pressing the space bar immediately switches the selection to an individual message, and displays it in the preview pane.

(In Thunderbird 91, the first press of the space bar did seem to attempt scrolling the summary page, but it didn't work correctly; the second press of the space bar then behaved the same as in Thunderbird 102)


Expected results:

Pressing the space bar should scroll the summary page, until it reaches the bottom. When the summary page is scrolled to the bottom, pressing the space bar should behave similar to how it does now in Thunderbird 102.

This was the behaviour of Thunderbird before 91.
Bug: Repair Folder modifies folder specific preferences
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-07-21 15:55:52+00:00
Resolved: 2022-07-22 00:34:58+00:00

I'm using Thunderbird 102.0.3 under Windows 11Pro with a Fastmail IMAP account.

The inbox is the currently selected folder. "View -> Sort by" has Date, Descending and Unthreaded selected. The folder columns are set to Display message thread, Sort by star, Attachments, Subject, From, Data and Size.

I right clicked on the inbox folder in the folder pane, selected Properties , pressed the Repair Folder button and then the OK button.

Actual result:

Lots of activity in the folder listing. New messages are now at the bottom. View -> Sort By for that folder has changed to Date, Ascending and Threaded. Folder columns has changed to Display message thread, Sort by star, Attachments, Subject, Sort by read, Correspondents, Junk status and Date

Expected result:

Any errors in the folder listing would be fixed, but none of the personal preferences (such as View -> Sort By or folder column settings) would be modified.

I don't know where folder specific settings are stored but if they are stored in the folders *.msf file they should not change (to default settings?) when you do a "repair folder". They should keep the current settings as is. I regularly suggest users use "repair folder" in the MozillaZine forums when they are missing messages in the folder listing. I can't remember a single time where those users mentioned the sort or column settings were wrong before using repair folder. They just wanted to get their messages back.
Bug: netwerk/test/unit/test_be_conservative.js, test_ech_grease.js, test_httpssvc_retry_with_ech.js, - tests from bug 1780014 don't work in Thunderbird
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2022-07-21 23:11:12+00:00
Resolved: 2022-07-29 08:39:56+00:00

Probably Telemetry probes we don't have. Investigating…
Bug: Shift-Delete on selected message(s) removes NEW/UNREAD status before confirming deletion
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2022-07-22 03:56:03+00:00
Resolved: 2023-11-06 12:18:45+00:00

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

Steps to reproduce:

Use SHIFT-DELETE to delete one or more new (unread) files.
Before clicking that you are sure and want to continue, notice that **the NEW (UNREAD) status has been removed.**



Actual results:

The NEW (UNREAD) status has been removed *before* actually committing to the deletion.



Expected results:

The NEW (UNREAD) status should remain intact in case user declines the deletion.  NEW status is moot *if* user confirms deletion, but otherwise should remain intact.  (But remove NEW status before moving to TRASH *if & when* user does a regular delete.)

*Case in point:*  With the recent bugs in TB 102 whereby sometimes-massive multiple downloads occur, the NEW status can be used to sort & group duplicates.  If I select the files for deletion and press Shift-Delete, then click CANCEL, the NEW status will have been removed and potentially lost unless I remember to take additional action.

Happened before TB 91 and continues in TB 102.
Running Windows 7/Pro 32-bit.

Severity probably S3 -- one can click the TAG button immediately after declining to restore the NEW status *if one remembers in time!*  Not serious, but can lead to tedious work trying to re-identify candidates for deletion.
Bug: Strip out potentially malicious Unicode sequences when replying
Status: REOPENED
Priority: --
Created: 2022-07-22 05:09:43+00:00
Resolved: 2024-03-21 15:15:39+00:00

Steps to reproduce:

Reply to an email with malicious Unicode sequences (note: I didn’t actually do this, but Ben Bucksch (:BenB) suggested in bug 1780423 comment 5 that I file a bug for it).


Actual results:

The malicious Unicode sequences are not stripped out, and could cause the recipient to receive a message that looks different than what I saw.


Expected results:

The malicious Unicode sequences are stripped out, so what I see when viewing the message is the same as what that I will see when replying to the message, and also the same as what the recipient of my reply will see.  This must hold for both HTML and plain text email, as well as for the automatically generated plain text MIME part of an HTML email.
Bug: Unnecessary console error during account setup: (NS_ERROR_NOT_IMPLEMENTED) [nsIAutoCompleteInput.popupElement] LoginManagerPrompter.jsm:90
Status: NEW
Priority: --
Created: 2022-07-22 08:11:24+00:00
Resolved: 2024-06-11 07:56:31+00:00

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

102.0.3 (64-bit), Win10

STR
- autoconfig of a GMX IMAP account on a fresh 102 install.

Actual result
- useless console error cluttering error console (which is far too red already, Bug #1780271)
- probably associated to the password input and the FF autocomplete algorithm for that

---

NS_ERROR_NOT_IMPLEMENTED: Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIAutoCompleteInput.popupElement] LoginManagerPrompter.jsm:90
    observe resource://gre/modules/LoginManagerPrompter.jsm:90
Bug: Error on writing a directory (filter) repeated for each mail treated
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2022-07-22 12:02:54+00:00
Resolved: 2022-09-05 14:01:04+00:00

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

Steps to reproduce:

Just receive mails


Actual results:

Error while filtering "Access error to the directory",
The error is repeated for each mail involved and must be acknowledged?
More the same errors are repeated at the rythm of the mail exploration timer (depending of type of error).
When there is a considerable number of mails, several hundredths, even thousands this locks the interface inoperant during long hours and needs the presence of the operator. (must click OK). Note that this is commonly combined with other types of errors that have, when repeated, the same behavior.
To receive 3,000 mails (after one week of inactivity) to stabilize reception can lead to one full day of work used to click...



Expected results:

When such error occurs, 
1- offer the option "skip other of same type"
2- Record all into an error log file, which allow to apply manually the failed treatment.
The can avoid multiple boring "clicks".
Reception treatment could be parameterized as "exclusively report errors in a log file" which will avoid for the operator to remain present during the whole treatment.
The log could be used to recycle the treatment, particularly when a filter fails to move a file to a directory. To create a list of failed filters and submit manually is a job. There are other types of errors that must be treated until the error log is empty...

I declare it as a "defect" because it is not normal to spend a so long time to receive their mails. 
Most of softwares like mass copy has such options to avoid having to click OK for each error necessarily repeated many times.
Bug: attachmentView height calculation ignores userChrome.css
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2022-07-22 12:14:42+00:00
Resolved: 2023-05-17 18:03:21+00:00

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

Steps to reproduce:

Having mailnews.attachments.display.start_expanded set to true in user.js  I tried to remove the attachment bar as there is no need for it anymore. So I set
#attachmentBar { 
  display: none!important;
}
in userChrome.css. 


Actual results:

It works in that the attachment bar vanishes, but the height of the attachmentView vbox  is still calculated as if the bar was there. Thus, the attachmentView vbox is too high. However, when selecting a different message and then going back to the one with the attachments, then the height is calculated correctly and the attachmentView vbox is the correct size. Likely the height initially is calculated before the userChrome.css has been read and applied. 

However, this happends for every mail. I.e., I start TB, select the first mail with attachments, size wrong. I select another mail and then the first one again => correct size. Now I select another mail with attachments => also wrong size and corrected on the second visit.

Thus it seems that every time I select another mail the size is again calculated without respecting what has been set in userChrome.css.


Expected results:

The height of the vbox should always be calculated after user css files were applied so that it is always has the correct size and not only on subsequent visits.
Bug: Wrong encoding garbles up French characters
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-07-22 13:07:23+00:00
Resolved: 2022-08-03 21:55:35+00:00

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

Steps to reproduce:

I updated Thunderbird last week and today.  Problem still there.
It is now Version 102.0.3, first offered to channel users on July 20, 2022


Actual results:

Since the update the french letters are changed to characters.  The encoding is greyed out and cannot be changed to Western.  In the advanced options, the encoding is not there anymore.


Expected results:

Not change to characters other than the real letters

For example:  Ã  vÃ©rifier si vous Ãªtes dans la trajectoire de dÃ©part ou dâarrivÃ©e de certains vols et si lâavion en question a bien respectÃ© les rÃ¨gles dâattÃ©nuations du bruit prÃ©sentement en vigueur Ã  lâaÃ©roport MontrÃ©al Saint-Hubert.
Bug: Unwanted tries to connect to a "disconnected" account
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-07-22 15:39:27+00:00
Resolved: 2022-08-10 12:58:08+00:00

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

Steps to reproduce:

Let TB do his job at starting


Actual results:

Mail accounts that have been "disconnected" (using 1-  "get new message at starting" unchecked 2- "check for new messages each x minutes" unchecked - no duration given) are nevertheless checked. Then some of these accounts (for which connection parameters are not available) generate the message (translated from French) "connection impossible to account" or "invalid password".


Expected results:

The account should not be checked.
Note: previously in the advanced parameter there was a checkbox (translated from French) "inactivate server for this account" it no more exists, then the alone way known that can be used to inactivate the checking of an account seems the process related above which doesn't function.
Such messages can be repeated several times because the time to check and send messages for other accounts can be longer than the "default" duration (no duration given) between two checks. Then the error is repeated regularly for a very long time (I had to acknowledge -click cancel or ok) for two days (thousands of times) because I was updating a computer that had been stopped for several weeks). This problem cumulates with the related 1780786.
Note that during such operations it is impossible to access to the TB interface (I had to use "cancel task" several times)
What is to solution to "set accounts sleepy"?
The request and more repeated is a defect
Bug: My unified inbox shows 0 messages, although the underlying accounts contain each many massages.
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2022-07-22 16:54:46+00:00
Resolved: 2022-08-01 03:18:33+00:00

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

Steps to reproduce:

Nothing: it stopped working by itself. I suspect the problem is related to the Mozilla ad which appears in the message window, instead of the selected message (see screenshot attached).


Actual results:

My unified inbox shows 0 messages, although there are many in the underlying accounts


Expected results:

By selecting the unified inbox, I should see a list of all the messages from all the accounts, sorted according to the selected criterion. The bar should show the total number of such messages (and not 0).
Bug: Repeated, stacked password requests for an account even after entering correct password
Status: RESOLVED
Priority: P3
Resolution: INCOMPLETE
Created: 2022-07-22 17:12:25+00:00
Resolved: 2023-01-30 01:18:57+00:00

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

Steps to reproduce:

Let run TB at the start


Actual results:

TB requests about an invalid password.
The password can be requested because if a valid case or because the account is closed or asleep (1780827).
The problem is that because of others' questions (unable to write a directory) or time to receive thousands of messages the timer loops on his delay (10 or 15mn depending on the account) then you can have into the stack of messages to acknowledge and questions to answer several times the same (the stack).
If you answer, for example, give the right password, the next identical question nevertheless will occur...
This is an incongruity that can lead to errors and is disturbing.



Expected results:

A question must appear only once and cannot be repeated while the previous is still in the stack, more the password can be checked again only if an answer has been given to the current. 
It is sure that most of the time I quite never answer (I cancel) because the password has not to be changed (the question is for a sleepy account) so I get repeatedly the same unwanted questions (can be ten to twenty times or more).
Bug: Address search does not work on imported Outlook address book,
Status: UNCONFIRMED
Priority: --
Created: 2022-07-22 22:40:03+00:00
Resolved: 2022-09-11 13:56:59+00:00

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

Steps to reproduce:

Open address book. Select the "Outlook" address book. (This was imported when I first started using version 32(?) which I then updated to 91.  Things worked fine. After update to 102 there are problems. 
1. When click on address no details shown. If I double click or select edit the details are shown but in a live edit format. Save. The addresses then all display their details if I click on one.
2. If I enter anyting in the search box nothing happens BUT all the entries except roughly the first 20 disappear. If I clear the search they reappear.
3. It will not carry through an export (I thought if export and re0import it might work).



Actual results:

Results as described in the steps box above.   Further comment - this happens only with the imported Outlook address book. The personal address book that Thunderbird created automatically seems to work ok.   But dragging an address from Outlook to the personal one seems to stop that searching too (erratically ie sometimes drag and drop works ok and there is no fault - sometimes it stops the search function in "personal" too


Expected results:

When letters are entered in the search box the list should reduce to just items with those letters.  When export is selected a CSV file should appear in the location selected for export.

I do not know what the user agent string is or where to find it.