av9ash/GitBugs huggingface dataset:
Bug: Linux Fedora: after update to 102.8 stopped to receive emails
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-02-20 09:37:54+00:00
Resolved: 2023-02-20 22:09:08+00:00

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36

Steps to reproduce:

Standard software update by yum/dnf


Actual results:

Thunderbird opens, shows "connecting to ....server-name..." and does nothing.
I had to set up email account on Evolution, there are many emails which Thunderbird does not show.


Expected results:

It should receive new emails. It does not
Bug: Not using default outgoing mail-server
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2023-02-20 10:57:55+00:00
Resolved: 2023-10-07 18:06:34+00:00

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

Steps to reproduce:

I had two outgoing servers, out1 and out2 with out2 marked as default, When investigating a problem sending e-mail to my gmail.com adress I noticed that changing the connection security for out2 the behaviour changed, but I still had a problem: ssl/tls => mail went to spam, starttsl => mail was rejected with a message that indicated that out1 was used.


Actual results:

After removing out1 Thunderbird asked for my password after which everything worked fine. Coclusion: Thunderbird used out1 with out2´s settings !!??
(out1 was mail.inet.fi, out2 is mail.oktanet.fi)
Bug: Intermittent comm/mail/test/browser/quick-filter-bar/browser_filterLogic.js | Uncaught exception in test bound test_filter_tags - TypeError: can't access property "scrollIntoView", button is null
Status: RESOLVED
Priority: P5
Resolution: WORKSFORME
Created: 2023-02-20 11:46:16+00:00
Resolved: 2024-08-30 00:07:43+00:00

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

---
```
Notably this test also doesn't pass --verify locally, but for different reasons, I think.
```
Bug: Message reader renders plain text gentle smile :) emoticon as strong "smile"/laugh 😄 emoji, which is an inappropriate distortion of tone
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-02-20 13:20:37+00:00
Resolved: 2023-06-12 12:07:21+00:00

Steps to reproduce:

Got an email with the ":)" emoticon.


Actual results:

Thunderbird replaces ":)" with the emoji 😄. 


Expected results:

Thunderbird should have replaced ":)" with a more similar emoji, e.g. 🙂. The current replacement gives a very different tone which can be very inappropriate.
Bug: Focused and pressed state of buttons on quick filter bar almost undiscoverable, and should be flat & borderless when unpressed on Windows
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2023-02-20 15:53:22+00:00
Resolved: 2023-04-24 19:51:28+00:00

Seen on 112.0a1 (2023-02-20) (64-bit)

Expanded from Elizabeth's accessibility analysis

New 3-pane makes all the buttons on quick filter bar focusable - that's great. However, their focused or pressed state is almost undiscoverable and needs some love. Also, all of these buttons should be flat & borderless on Windows when not pressed (as on TB 102).

Richard?

Actual (see screenshot):
- Focused button not discoverable (`Starred` button has focus with very faint grey border)
- Pressed button not discoverable (`Tags` button is pressed, but hardly distinct from others)
- Unpressed buttons stand out from the entire flat UI with needless border
- `Any of/All of` selector looks alien

Expected
- Clear and consistent app-wide focus distinction (thick blue border)
- Clear contrast between unpressed (flat, borderless) vs. pressed (can then keep the inside shadow) as in TB 102.
- Unpressed buttons should be flat and borderless (as seen on TB 102) for
  - less saliency when unpressed (calm UI)
  - better distinction against pressed state
  - ux-consistency with our overall flat design (e.g. buttons on Places toolbar)
  - ux-consistency with Windows OS
- Make `Any of/All of` selector blend in better (font-size, border, etc.)
Bug: `Restore Column Order` of thread pane doesn't do anything
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-02-20 21:41:14+00:00
Resolved: 2023-04-24 19:49:45+00:00

112.0a1 (2023-02-20) (64-bit)

Thread pane columns on IMAP were acting up, showing wrong set of columns in wrong order (all small columns in front, as in bug 1612055), and thread column gone (restorable). So I tried "Restore Column Order", which did nothing.

If anyone can reproduce, kindly let me know.

STR
- Hide and show some columns of threadpane (e.g. Correspondents) from column picker, so that you don't have the default set. We need a non-default column order - for me it just happened, not sure how to force that as we cannot reorder columns yet.
- From column picker, choose "Restore Column Order".

Actual
- Nothing

Expected
- Reorder all chosen columns in default order

Btw: Why don't we have "Restore default set of columns"??
Bug: Tags are not shown in message list
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-02-20 21:46:21+00:00
Resolved: 2023-04-24 19:49:46+00:00

Steps to reproduce:

1. Tag a message
2. Check that message in the message list: font & focus color


Actual results:

Tagged and not tagged messages have identical styling.


Expected results:

Tagged messages should :
1. have the font color of the tag
2. have focus color of the tab when focused

Regression from TB110b4
Bug: Unread messages no longer standing out enough in message list with TB's Dark theme, as read messages are now brighter than before
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-02-20 21:57:22+00:00
Resolved: 2023-04-24 19:51:23+00:00

Steps to reproduce:

1. Set the dark theme
2. Open a folder with an unread message


Actual results:

Hard to differentiate the unread and read message in message list. It's not enough obvious


Expected results:

It should be more obvious, from the first and rapid sight.

Regression : It was the case in TB 102 and TB110b4

In the screenshot, compare how it is easy to identify read status of bug 1811366 in the list
Bug: Collapsing/Expanding thread doesn't toggle between multi-message vs. single message view
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-02-20 21:59:10+00:00
Resolved: 2023-05-30 22:59:16+00:00

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

112.0a1 (2023-02-20) (64-bit)

Mouse action directly on the threads expand/collapse toggle seems to have the same problem. Beware of artifacts when multiple messages are selected (which is the only thing which seems to work).

STR1
- Threaded view with threads
- select only msg 1 of open thread
- press cursor left on msg 1 to collapse thread

STR2
- Threaded view with threads
- select msg 2 of open thread, then shift+cursor up to select msg 1, too (now both selected, focus on msg 1)
- press cursor left on msg 1 to collapse thread
- press cursor right to expand thread

Actual
- STR1: For collapsed thread, still shows single message
- STR2: For Expanded thread, still shows multi-message view although only msg 1 is selected.

Expected:
- STR1: For collapsed thread, need to show multi-message in msg reader
- STR2: For expanded thread with only first msg selected, need to show single message in msg reader
Bug: Drop-down textfield font with Dark theme should not be black
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-02-20 22:16:29+00:00
Resolved: 2023-04-24 19:31:28+00:00

Steps to reproduce:

1. Click write a new email
2. Open a Calendar tab


Actual results:

Drop-down textfield font with Dark theme should not be black


Expected results:

Drop-down textfield font with Dark theme should respect Dark theme colors
Bug: Calendar dark theme issues
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-02-20 22:28:03+00:00
Resolved: 2023-02-27 09:08:20+00:00

Steps to reproduce:

1. Set the dark theme
2. Open a Calendar tab


Actual results:

Many things do not respect dark theme colors :
1. Event filter drop-down : black text on black background
2. Calendar toolbar : Text and icons are black on a black background
3. Task panel header : shown styled with light theme


Expected results:

All components should respect dark theme colors

Regression from TB110b4
Bug: Message reader often does not show the content of the focused message after delete
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2023-02-20 22:42:12+00:00
Resolved: 2024-02-19 07:07:15+00:00

Steps to reproduce:

1. Select a message and delete it
2. Repeat


Actual results:

1. The next message is selected in Message list
2. The Message reader isn't updated to show the content of that newly selected message


Expected results:

The Message reader should be updated to show the content of the newly selected message after delete.

Regression : TB 110b4

Reported against Message list as:
- the bug appeared after message list rewrite;
- the bug seems related to message list even if visible in message reader.
Bug: Intermittent comm/mail/components/addrbook/test/browser/browser_cardDAV_init.js | uncaught exception - "TypeError: class heritage customElements.get(...) is not an object or null
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2023-02-20 22:57:01+00:00
Resolved: 2023-02-27 23:54:43+00:00

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

---
```

```
Bug: Intermittent comm/mail/components/extensions/test/browser/browser_ext_bug1812530.js | Test timed out
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2023-02-20 23:00:33+00:00
Resolved: 2023-05-08 06:40:24+00:00

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

---
```

```
Bug: Collapse and Expand threads don't invalidate the tree after using quick filters
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2023-02-20 23:57:12+00:00
Resolved: 2023-04-24 19:43:14+00:00

STR
- Toggle ON and OFF any of the quick filter buttons
- All threads should be opened after toggling OFF
- Press `\` to collapsed all threads

These command actually work, but the tree is not invalidated, therefore the UI still shows the opened threads.
This happens only after toggling a quick filter button. Without interacting first with the QFB, everything works normally.

This used to work last week, so something recent must have regressed it.
Bug: message list always showing top emails irrelevant to sort order
Status: RESOLVED
Priority: P1
Resolution: DUPLICATE
Created: 2023-02-21 01:03:58+00:00
Resolved: 2023-04-24 19:49:38+00:00

Steps to reproduce:

Coming from Bug #1815944

I have 30 accounts, 10-50 folders each. I click on A1F5 it is sorted by date ascending so top of the list of emails are emails from 20 years ago, bottom is new emails I care about, list is showing top 20 emails (so something 20 years old), I have to scroll the list to the bottom to see new email, I select last (newest) one. I click now on A2F7 same thing, same sort by date asc, same thing showing me emails 30 years old, I scroll down to the latest emails, click on the last one select it. I click now back on A1F5 again I'm shown top of the list with 20year old emails instead of end of the list (bottom of the list) where the new emails are and where the one I previously selected is. Everything inside one single tab.

So the major issue here is, irrelevant to what email was selected previously, the initial view of the message list should make sense. Either remember the relative position of the "window / scroll bar" or always show latest emails or .. makes no sense to always show emails from decades ago ... so if list is sorted by date depending on asc/desc you should show end or beginning of the list, or store relative scroll bar position. This used to work ok earlier not sure how it was changed now that it always show the top of the list



Actual results:

message list always have scroll position at top showing emails from decades ago instead of new ones


Expected results:

remember scroll position, top or bottom, whatever I left it at last time
Bug: Right clicking on/in the search bar field should trigger the simple context menu for input fields
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-02-21 05:03:11+00:00
Resolved: 2023-04-24 19:51:50+00:00

A right click on the search bar triggers the unified toolbar context menu with the "Customize" action.
It should trigger the standard context menu with the usual copy, paste, undo, redo, etc, triggered from other input fields.

We're very inconsistent with this, so not many great examples in the application, but the best one is the `#searchInput` in the Address Book.
Bug: Folder and message list panes are empty
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2023-02-21 07:45:06+00:00
Resolved: 2023-03-06 13:35:41+00:00

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

Steps to reproduce:

1. I run the Thunderbird application on the Mac OS X Ventura 13.1 Apple M1 operating system.
2. On the bottom bar, which shows what emails I am currently downloading, everything indicates that my emails are normally downloading on my mailboxes.
3. I'm waiting but nothing is shown.


Actual results:

I do not show, no resulting data from the boxes that I have configured in the Thunderbird program.


Expected results:

A normal view of mailboxes and my list of e -mails and details of the selected email, which I will choose to read.
Bug: Changing folder makes the mail list go up
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-02-21 10:08:17+00:00
Resolved: 2023-04-24 19:49:30+00:00

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

Steps to reproduce:

Open Thunderbird, open an e-mail folder, open another folder.


Actual results:

The mail list systematically go up, regardless of the e-mails sorting rule. For me, the last e-mails appear at the bottom, so I have to scroll down every time.


Expected results:

Not reset the scrolling, I guess, and show me either my last placement in the scroll, or show me the bottom of the list, corresponding to the last of my e-mails.
Bug: [OpenBSD] failure to open links in the browser since #1714919
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-02-21 11:14:00+00:00
Resolved: 2023-04-24 16:35:45+00:00

Just filing a bug as a reminder for myself.. thunderbird 102 works perfectly fine and isnt sandboxed/pledged/unveiled on OpenBSD.

Trying 110.0beta4, opening links in mails fail:
```
[Parent 64370, Main Thread] WARNING: Could not find content type for URI: https://jitsi.hivane.net/craig-ihedn: 'glib warning', file /usr/obj/ports/thunderbird-110.0beta4/thunderbird-110.0/toolkit/xre/nsSigHandlers.cpp:167

** (thunderbird-default:64370): WARNING **: 12:05:07.432: Could not find content type for URI: https://jitsi.hivane.net/craig-ihedn
[Parent 64370, Main Thread] WARNING: Could not launch default application for URI: Could not find content type for URI: https://jitsi.hivane.net/craig-ihedn: 'glib warning', file /usr/obj/ports/thunderbird-110.0beta4/thunderbird-110.0/toolkit/xre/nsSigHandlers.cpp:167

** (thunderbird-default:64370): WARNING **: 12:05:07.432: Could not launch default application for URI: Could not find content type for URI: https://jitsi.hivane.net/craig-ihedn
```
opening pdfs in the internal pdf viewer works, opening docx/ods files properly starts libreoffice.

this is most probably caused by code added in bug #1714919 to handle opening urls/files in a sandboxed firefox, but this might have the bad side effect of breaking thunderbird.

will investigate, my first guess is that `g_content_type_guess` in https://searchfox.org/mozilla-central/source/toolkit/system/gnome/nsGIOService.cpp#268 fails on urls, which makes sense. I'll have a look at how glib handles non file urls...
Bug: Intermittent comm/mail/test/browser/content-policy/browser_generalContentPolicy.js | Error: Video was not allowed in standalone message content
Status: NEW
Priority: P5
Created: 2023-02-21 12:07:26+00:00
Resolved: 2024-03-25 06:53:16+00:00

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

---
```

```
Bug: Extension install panels have no background color on their primary buttons
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-02-21 13:05:31+00:00
Resolved: 2023-02-23 21:54:05+00:00

STR:
- Install an extension
- Observe the install prompt popup

Expected results:
The primary action is a blue button with the label "Add"

Actual result:
The primary action is a button without a background.

I think this is because these panels use styles from toolkit, which use a variable we no longer provide: https://searchfox.org/mozilla-central/rev/d85572c1963f72e8bef2787d900e0a8ffd8e6728/toolkit/themes/shared/global-shared.css#232
Bug: Poor contrast of enabled/disabled/hover status of the Quick filter bar buttons in Light & Dark theme
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-02-21 15:38:31+00:00
Resolved: 2023-02-23 17:00:52+00:00

The enabled/disable/hoover status of the Quick filter bar buttons isn't clearly visible (only the button border change). It should be improved (Light & Dark theme), so the user have a clear indication of which are enabled/disabled.

It was visually okay on TB102 & TB110b4 with dark theme
Just visible for the enabled status on TB102 & TB110b4 with light theme (if button background color would change a bit it would be more clear I think)
Bug: Default width of 3pane is too narrow
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-02-21 16:25:06+00:00
Resolved: 2023-04-24 19:31:08+00:00

On a fresh profile, `messenger.xhtml` sets a default width of 1024px (or smaller if a narrow screen).
https://searchfox.org/comm-central/rev/7559777da5005a906731e9622f92569489e0862c/mail/base/content/messenger.js#194-209

Realistically, this is too small. On Windows, the Mail tab is usable unless the today pane is enabled, then the message list and display boxes are too small to be useful. The Calendar tab is worse, at 1024px wide the default week display (week being the default view) cuts off at either Thursday or Saturday depending if the Today Pane is visible. Month/Multiweek compress the day widths so the entire week is visible, but the display of the event itself cuts off at the start time, so you cannot see the description.

**It looks like a width of 1329px is sufficient to display the Calendar in week view with the Today Pane and not cut off days.**

We should have our own telemetry on this (maybe?) -- but even if not, the [Firefox Public Data Report](https://data.firefox.com/dashboard/hardware) has useful information: 65% of screens use either 1920x1080 or 1366x768. Of the remaining 35%, 8% fall into an "Other" category that includes widths less than 1024px as well as above.

Using (older) data from https://firefoxgraphics.github.io/telemetry/#view=monitors, we can get more specific:

| Width (as w)      | Count  | Increment % |   | Width (as w) | % Smaller |
|-------------------|--------|-------------|---|--------------|-----------|
| w <= 1024         | 26115  | 2.42%       |   | w <= 1024    | 2.42%     |
| 1024 < w <= 1080  | 2927   | 0.27%       |   | w <= 1080    | 2.69%     |
| 1080 < w <= 1152  | 1555   | 0.14%       |   | w <= 1152    | 2.83%     |
| 1152 < w <= 1280  | 55556  | 5.14%       |   | w <= 1280    | 7.97%     |
| 1280 < w <= 1366  | 257484 | 23.81%      |   | w <= 1366    | 31.78%    |
| 1366 < w <= 1440  | 30296  | 2.80%       |   | w <= 1440    | 34.58%    |
| 1440 < w <= 1600  | 73241  | 6.77%       |   | w <= 1600    | 41.36%    |
| 1600 < w <= 1680  | 24683  | 2.28%       |   | w <= 1680    | 43.64%    |
| 1680 < w <= 1920  | 545072 | 50.41%      |   | w <= 1920    | 94.05%    |
| 1920 < w <= 2560  | 34529  | 3.19%       |   | w <= 2560    | 97.24%    |
| 2560 < w <= 3840  | 28677  | 2.65%       |   | w <= 3840    | 99.89%    |
| 3840 < w <= 11880 | 1161   | 0.11%       |   | w <= 11880   | 100.00%   |

94% of Firefox Desktop users have screens <= 1920px wide. We should take advantage of this width by default and not make users adjust the window themselves. First impressions and all that good stuff.

Personally, the first thing I do after setting up an account on a new profile is adjust the window size so it's useful. I see this as an easy win.

In terms of CI testing, Windows tests run at 1280x1024, Linux at 1600x1200, and macOS at 1920x1080. I don't see anything specifically testing the width of messenger.xhtml. It should be added.
Bug: Sometimes the visually selected row is not really the selected row
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2023-02-21 19:33:39+00:00
Resolved: 2023-05-06 16:51:21+00:00

I don't have steps to reproduce since it only happens sometimes. But sometimes the row that is visually selected is not the really selected row in the new message list.

Please see this video:

https://www.youtube.com/watch?v=BjnWQO8WXro

You can see that one row has the background color for a selected row. Then I press the 'S' key several times to mark and unmark the message with a star icon. As you can see not the star icon of the row with the backgroud color changes its state but the row above.

Tested in Thunderbird Daily 112.0a1 (2023-02-21) on macOS 13.2.
Bug: Can't Drag and Drop Attachments into Compose Window
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2023-02-21 19:36:14+00:00
Resolved: 2023-02-22 22:44:15+00:00

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

Steps to reproduce:

Compose new email then attempt to drag and drop attachment from windows explorer.


Actual results:

Icon being dragged changes to prohibition sign (circle with cross line through it) when over thunderbird windows


Expected results:

Attachment options for inline vs. attached should show up
Bug: IMAP: Advanced Search messages cannot search body, because `body` field is missing
Status: UNCONFIRMED
Priority: --
Created: 2023-02-21 19:49:08+00:00
Resolved: 2024-12-07 21:53:13+00:00

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

Steps to reproduce:

Edit->Find->Search messages
In this dialog I can specify multiple search criteria. 


Actual results:

The option for searching message body does not exist. Sometime since TB-68 it has been removed. 
Customize does not help, because it stipulates only custom headers.


Expected results:

The search messages function is a half-cripple if it cannot also search the body of the messages.

Example criteria I needed today, which works in TB-68, but not in TB-102.8:
From: contains email_address
Body: contains some_string

Please restore this lost functionality. Thank you.