av9ash/GitBugs huggingface dataset:
Bug: Proton: difficult to distinguish active tab
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-06-02 02:00:31+00:00
Resolved: 2021-06-02 02:10:00+00:00

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

Steps to reproduce:

Updated to 89.0


Actual results:

New design made it difficult to distinguish active tab.

Proton offers two options to do this:
1) Background color of active tab is different than inactive
2) Active tab has border and shadow, inactive doesnt

Both fail and dont help.

1) Background color based option dont help as there is a small contrast ratio between tab background colors. 
Contrast ratio between active/inactive tabs background colors is 1.14:1 for light mode, and 1.70:1 for dark mode, while WCAG requirement for active user interface components is 3:1 (AA).

Personal expetience: I got perfect sight, and it is difficult for me to distinguish active tab using background color.

2) Border and shadow based option dont has help as inactive tab has same background color as address bar.
It confuses: it looks like inactive tab and active page are joined (just like active tab and active window was joined before Proton), so we percept inactive tab as active.

As far as tab is not connected to the opened page (in proton you made tabs look like buttons) it is not intuitive, confusing behavior. 

Personal experience: I use computers from the childhood, this interface decision confusing me.

3) Multi Account Containers:

Container tabs make it even more confusing: if inactive tab is opened in , as for example, yellow container, we percept it as hightlighting of active tab (instead of highlighting container tab). 

Examples:

Example 1 (dark mode, has container tabs): https://disk.yandex.ru/i/5aufarK7TmQ-DA
Example 2 (light mode, has container tabs): https://disk.yandex.ru/i/6S92VFBlcR2jWQ

Looking on these screenshots i percieve "Bugzilla Main Page" as active tab, because it has same background as neighbour, but has the most bright (contrasting) color (orange). Really active tab (youtube) precieved like background/inactive/pinned. Summary: active tab looks like active, inactive tab looks like active. Interface goal is not reached: totally confusing design.


Expected results:

It's easy  to distinguish active tab. Current active tab is obvious.
Bug: Proton: difficult to distinguish active tab
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-06-02 02:09:40+00:00
Resolved: 2021-06-02 15:13:24+00:00

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

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

Steps to reproduce:

Updated to 89.0


Actual results:

New design made it difficult to distinguish active tab.

Proton offers two options to do this:
1) Background color of active tab is different than inactive
2) Active tab has border and shadow, inactive doesnt

Both fail and dont help.

1) Background color based option dont help as there is a small contrast ratio between tab background colors. 
Contrast ratio between active/inactive tabs background colors is 1.14:1 for light mode, and 1.70:1 for dark mode, while WCAG requirement for active user interface components is 3:1 (AA).

Personal expetience: I got perfect sight, and it is difficult for me to distinguish active tab using background color.

2) Border and shadow based option dont has help as inactive tab has same background color as address bar.
It confuses: it looks like inactive tab and active page are joined (just like active tab and active window was joined before Proton), so we percept inactive tab as active.

As far as tab is not connected to the opened page (in proton you made tabs look like buttons) it is not intuitive, confusing behavior. 

Personal experience: I use computers from the childhood, this interface decision confusing me.

3) Multi Account Containers:

Container tabs make it even more confusing: if inactive tab is opened in , as for example, yellow container, we percept it as hightlighting of active tab (instead of highlighting container tab). 

Examples:

Example 1 (dark mode, has container tabs): https://disk.yandex.ru/i/5aufarK7TmQ-DA
Example 2 (light mode, has container tabs): https://disk.yandex.ru/i/6S92VFBlcR2jWQ

Looking on these screenshots i percieve "Bugzilla Main Page" as active tab, because it has same background as neighbour, but has the most bright (contrasting) color (orange). Really active tab (youtube) precieved like background/inactive/pinned. Summary: active tab looks like inactive, inactive tab looks like active. Interface goal is not reached: totally confusing design.


Expected results:

It's easy  to distinguish active tab. Current active tab is obvious.
Bug: Proton: inconvenient controlling tab sound (mute/playing)
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-06-02 03:00:56+00:00
Resolved: 2021-06-13 01:28:09+00:00

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

Steps to reproduce:

Upgraded Firefox to 89.0


Actual results:

New design made it inconvenient to control tab sound.

1. Distinguishing playing tab
How it was: there was a "volume" icon on tab
How it became: tab has text label "PLAYING" under the tab title.

Icon is a better way to distinguish playing state. Formerly used icon is widely used recognizable, and clearly determines its meaning. It was easy to use. Through the time, we won't read text label "PLAYING", we will accept it as an icon.

If it is possible to use icon (icon meaning is recognizable), better to use it instead of text label, for faster navigation. Faster navigation -> better UX.

Steps before: 1) find tab containing recognizable icon
Steps now: 1) find tab containing text "Playing" under the tab title

I liked

2) Muting/unmuting playing tab
How it was: there was a "volume" icon on tab, you could hover on it and then click to toggle tab sound state
How it became: tab has text label "PLAYING" under the tab title. after you hover on the tab, you have to notice that tab favicon changed to "volume" icon, hover on it (clickable area is about 1/2 cursor, so be accurate).

Steps before: 1) find tab containing recognizable icon 2) hover on icon 3) click on it to toggle tab sound state
Steps now:  1) find tab containing text "Playing" under the tab title 2) hover on it 3) notice that tab favicon changed to the widely recognizable icon "volume" 4) hover on it (clickable area is about 1/2 cursor, so be accurate) 5) click on it

As fas as sound control button (icon "volume") is small, you should make an effort to hover cursor on it.

Summary:
Proton made controlling tab sound inconvenient. Now it is more difficult, and less untuitive.

1) It is not intuitive that tab sound control button (volume icon) shows a) only when you hover the tab b) it is located in place of favicon. Double "WAT?".
2) Tab sound control button (volume icon) is too small, you should make an effort to position on it. Why having so huge tab, if it's controls are so small?
3) Why tab state ("playing") and state control element (small volume icon, that appears when you hover the tab) separated? Text label "playing/mute" does not provide any different information comparing to "volume" icon. But icon is all-in-one: a state indicatior and control element, it is convenient.


Expected results:

1) It is easy to distinguish playing tab
2) Clickable area of sound control button ("volume icon") is enough to not require additional effort to locate on it (now it is too small)
3) Sound control button ("volume icon") is visible if tab playing sound. I can locate control element without hovering the tab.
Bug: Ordering tabs using mouse drag is laggy (Linux/GTK3).
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-06-02 05:04:55+00:00
Resolved: 2021-08-03 18:20:58+00:00

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

Steps to reproduce:

1. Open a few tabs
2. Try to reorder them using mouse drag.


Actual results:

Tab ordering works but is very laggy. This did not happen in previous Firefox versions.


Expected results:

Tabs should be dragged and moved smoothly, without any lags.
Bug: Proton: incostistent size of tab controls ("mute/unmute" 16x16px vs "close (x)" 24x24px)
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-06-02 05:34:26+00:00
Resolved: 2021-06-02 05:36:45+00:00

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

Steps to reproduce:

Upgraded to Firefox 89


Actual results:

Mute/Unmute tab control ("volume" icon) size is less than tab close control ("x" icon).  This issue makes audio control button inconvenient to use.

Clickable areas:
1) Mute/Unmute control ("volume" icon): 16x16 px
2) Tab close button ("x" icon): 24x24px

Tab control sizes are incostistent.
Bug: Proton: incostistent size of tab controls ("mute/unmute" 16x16px vs "close (x)" 24x24px)
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-06-02 05:36:31+00:00
Resolved: 2021-08-03 18:34:59+00:00

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

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

Steps to reproduce:

Upgraded to Firefox 89


Actual results:

Mute/Unmute tab control ("volume" icon) size is less than tab close control ("x" icon).  This issue makes audio control button inconvenient to use.

Clickable areas:
1) Mute/Unmute control ("volume" icon): 16x16 px
2) Tab close button ("x" icon): 24x24px

Tab control sizes are incostistent.

Expected results:
Mute/unmute ("volume" icon) and Close tab ("x" icon) have the same clickable area size (24px+)
Bug: Chrome bookmarks import does not import the contents of the "other bookmarks" folder
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2021-06-02 05:48:27+00:00
Resolved: 2022-11-15 05:19:17+00:00

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

Steps to reproduce:

I have installed the last version of Firefox. It installed properly. However, after importing the bookmarks from Google Chrome, the "other bookmarks" were not imported.  See screenshot https://prnt.sc/13pe9zi "

Afterwards, I uninstall Firefox using  https://www.revouninstaller.com/ 
including all hidden files.
Then again installed Firefox . But once more the "other bookmarks" were not imported.  The rest of bookmarks are OK!


Actual results:

All explained above


Expected results:

All bookmarks should be imported
Bug: 12.02% tart (Linux) regression on Thu May 27 2021
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-06-02 06:26:30+00:00
Resolved: 2021-06-03 08:52:16+00:00

Perfherder has detected a talos performance regression from push [257c3c51ab2338a35634610b9d3c6c4c305e6005](https://hg.mozilla.org/integration/autoland/pushloghtml?changeset=257c3c51ab2338a35634610b9d3c6c4c305e6005). As author of one of the patches included in that push, we need your help to address this regression.

### Regressions:

| **Ratio** | **Suite** | **Test** | **Platform** | **Options** | **Absolute values (old vs new)**| 
|--|--|--|--|--|--| 
| 12% | tart [(docs)](https://firefox-source-docs.mozilla.org/testing/perfdocs/talos.html#tart) |  | linux1804-64-shippable-qr | e10s stylo webrender-sw | 3.67 -> 4.11 |


Details of the alert can be found in the [alert summary](https://treeherder.mozilla.org/perfherder/alerts?id=30217), including links to graphs and comparisons for each of the affected tests. Please follow our [guide to handling regression bugs](https://wiki.mozilla.org/TestEngineering/Performance/Handling_regression_bugs) and **let us know your plans within 3 business days, or the offending patch(es) will be backed out** in accordance with our [regression policy](https://www.mozilla.org/en-US/about/governance/policies/regressions/).

For more information on performance sheriffing please see our [FAQ](https://wiki.mozilla.org/TestEngineering/Performance/FAQ).
Bug: URLs in Cyrillic can't be deleted manually from History
Status: NEW
Priority: P5
Created: 2021-06-02 06:27:18+00:00
Resolved: 2021-06-23 13:28:23+00:00

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

Steps to reproduce:

I was manually cleaning out my History, and some History entries could not be deleted. These entries have one thing in common: they were URLs in Cyrillic and they cannot be deleted manually from History. See the attachment.

The only way these entries could be deleted was to wipe the entire History via Settings.


Actual results:

URLs in Cyrillic cannot be deleted manually from History. See the attachment.


Expected results:

When press Delete button URLs in Cyrillic should be deleted from History.
Bug: 3.96% tsvgx (Linux) regression on Wed May 26 2021
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2021-06-02 07:08:04+00:00
Resolved: 2021-06-03 16:39:44+00:00

Perfherder has detected a talos performance regression from push [deba1ae62f149225a158aa517fd63df8130522e3](https://hg.mozilla.org/integration/autoland/pushloghtml?changeset=deba1ae62f149225a158aa517fd63df8130522e3). As author of one of the patches included in that push, we need your help to address this regression.

### Regressions:

| **Ratio** | **Suite** | **Test** | **Platform** | **Options** | **Absolute values (old vs new)**| 
|--|--|--|--|--|--| 
| 4% | tsvgx [(docs)](https://firefox-source-docs.mozilla.org/testing/perfdocs/talos.html#tsvgx) |  | linux1804-64-shippable-qr | e10s stylo webrender-sw | 186.85 -> 194.24 |


Details of the alert can be found in the [alert summary](https://treeherder.mozilla.org/perfherder/alerts?id=30260), including links to graphs and comparisons for each of the affected tests. Please follow our [guide to handling regression bugs](https://wiki.mozilla.org/TestEngineering/Performance/Handling_regression_bugs) and **let us know your plans within 3 business days, or the offending patch(es) will be backed out** in accordance with our [regression policy](https://www.mozilla.org/en-US/about/governance/policies/regressions/).

For more information on performance sheriffing please see our [FAQ](https://wiki.mozilla.org/TestEngineering/Performance/FAQ).
Bug: Show the translation-related preferences also when `extensions.translations.disabled` is false
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-06-02 07:22:17+00:00
Resolved: 2021-07-14 16:33:10+00:00

Currently, the (`browser.translation.ui.show`) pref is responsible for showing both the legacy translations infobar and the translation-related preferences in `about:preferences` ([Screenshots](https://github.com/mozilla-extensions/bergamot-browser-extension/issues/16#issuecomment-774372930)).

If also the `extensions.translations.disabled` pref control the display of the translation-related preferences, the following issue is addressed: [Unable to reset blocked websites/languages bug](https://github.com/mozilla-extensions/bergamot-browser-extension/issues/199)
Bug: The click area of the "Learn more" link from the “Import Error” modals is too large
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2021-06-02 07:43:31+00:00
Resolved: 2021-07-07 11:59:53+00:00

[Affected versions]:
- Firefox Nightly 91.0a1 (Build ID: 20210601213358)

[Affected Platforms]:
- Mac 11.2.3
- Windows 10 x64
- Ubuntu 20.04 x64

[Prerequisites]:
- Have the latest version of Firefox Nightly installed.
- Have the “signon.management.page.fileImport.enabled” pref set to “true” value in the “about:config” page.

[Steps to reproduce]:
1. Open the Firefox browser with the profile from prerequisites.
2. Navigate to the "about:logins" page.
3. Click on the Menu button.
4. Select the “Import from a File…” option.
5. Select a non-CSV file and click on the “Open” button from the “Import Logins File” picker.
6. Hover the white space beside the "Learn more" link and observe what happens.

[Expected result]:
- The link is not highlighted.

[Actual result]:
- The link is highlighted and if you click the white space you are redirected to the specific link.

[Notes]:
- Also, the focus of the “Learn more” link seems to be too large.
- Attached a screen recording of the issue.
Bug: Facebook feed gets smaller after turning on the menu sidebar
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-06-02 07:45:23+00:00
Resolved: 2021-06-03 20:25:29+00:00

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

Steps to reproduce:

When you turn the menu toolbar on or the Bookmark toolbar, the Facebook feed gets around 20% smaller, which  is not ideal. If you turn off both of those toolbars, the Facebook feed regains its original size.


Actual results:

Facebook feed (main page) gets around 20% smaller when you have menu or bookmarks toolbar turned on.


Expected results:

The Facebook feed should stay the same size no matter which toolbars are turned on or off.
Bug: The new Proton UI is blinding on Windows 7 with Aero enabled
Status: NEW
Priority: --
Created: 2021-06-02 07:52:37+00:00
Resolved: 2022-12-18 12:28:20+00:00

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

Steps to reproduce:

Use Firefox 89 on a Windows 7 computer with Aero enabled.


Actual results:

The UI is blinding, especially the tab bar; choosing another official browser theme does practically nothing (e.g. when you choose the dark theme, the tab bar is still bright). Also, the text on transparent tabs is difficult to read.

Screenshots: https://imgur.com/a/APOxtXj


Expected results:

The tab bar should be less transparent and change with the themes. I'm not entirely sure how to make it better.
Bug: Lack of subpixel anti-aliasing in tab, side and status bar in Proton
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-06-02 09:14:29+00:00
Resolved: 2023-09-05 14:58:26+00:00

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

Steps to reproduce:

- Open FF Nightly 91 and compare to FF 88. 
- Analyse the fonts with "Digital Color Meter" on macOS


Actual results:

There is grayscale anti-aliasing in Proton's tab bar, side bar and the status bar that you have when you press "Ctrl + F"

Firefox 91: https://imgur.com/a/6H7J8Nt 


Expected results:

Before Proton you had proper sub-pixel anti-aliasing in both tab and status bar. 

Firefox 88: https://imgur.com/a/5adspaI

The side bar had grayscale anti-aliasing even in Firefox 88, but proper sub-pixel AA would be preferable here as well.
Bug: browser.tabs.onTop not found
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-06-02 09:53:46+00:00
Resolved: 2021-12-31 11:51:49+00:00

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

Steps to reproduce:

Open Firefox
Seems I have just been upgraded to Firefox 89 Windows 10 64 bit.



Actual results:

The tabs menu is above everything. 


Expected results:

The tab menu should be were it has always been - below all menus..

On researching browser.tabs.onTop option does not exist?

I have just wasted 40 minutes on this - don't do this - ask you user is they want the change..
Bug: Active tab only has two letters of page title, 2nrw.
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-06-02 10:53:51+00:00
Resolved: 2021-06-08 20:12:03+00:00

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

Steps to reproduce:

Create a tab


Actual results:

The tab is very narrow. Unhovered it has 3 letterers visible, and only 2 when hovered. Inactive tabs have 4.5 letters, which is good. But I need to work with active tabs as well.


Expected results:

I would expect more letters to be visible with less visual clutter.
Well, may be a paid feature to have firefox show more letters of the page title. Like $1 for each additional letter for those who likes letters.
Bug: Tab title in arabic moves while mouse pointer pass over it
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-06-02 10:57:55+00:00
Resolved: 2021-06-02 11:06:38+00:00

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

Steps to reproduce:

See attached video for more info.

Firefox: 89.0 (64-bit)
Operating System: Manjaro Linux
KDE Plasma Version: 5.21.5
KDE Frameworks Version: 5.82.0
Qt Version: 5.15.2
Kernel Version: 5.4.118-1-MANJARO
OS Type: 64-bit
Graphics Platform: X11
Bug: Lazy instances of NimbusFeatures don't resolve ready() as fast
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-06-02 11:02:12+00:00
Resolved: 2021-06-14 21:57:12+00:00

A lazily instantiated NimbusFeature will miss the `"remote-defaults-finalized"` event and resolve `.ready()` on timeout 15 seconds later.
Bug: "Send Tab to Device" does not show success feedback if account button is within Overflow menu
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2021-06-02 13:14:07+00:00
Resolved: 2021-07-29 18:55:53+00:00

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

Steps to reproduce:

1. Sign in to Firefox account.
2. Move "Firefox account" toolbar button into the "Overflow Menu"
3. Send any tab to another device


Actual results:

No visual indication appears that the operation succeeded.

Tested with Firefox 89.0 (64-bit) on Windows 10 as well as a clean installation of Firefox Nightly 91.0a1 (2021-06-01) (64-bit).


Expected results:

A visual indicator (tick mark with text "Sent!" next to application menu toolbar button) should be shown as is the case when the Firefox account toolbar button is completely removed.
(Related: https://bugzilla.mozilla.org/show_bug.cgi?id=1701544)
Bug: Firefox 90 default home page: search entry field not working;  typed entry does not appear in the main field but instead in the address bar.
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-06-02 13:51:23+00:00
Resolved: 2021-06-02 16:22:55+00:00

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

Steps to reproduce:

Enter a search term in Firefox default home page main search field.


Actual results:

Typed entry doesn't appear in search field. However, the typed entry jumps to and appears in the address bar even though the option to disable address bar search funtion has been set.


Expected results:

When I enter something in the Firefox Home Page search field, I would expect it to function. Has it been deprecated? This breaks a rudimentary browser function. I can't imagine continued use if this is now the default behavior. I have re-installed the browser, disabled add-ons, started in safe mode, and the issue remains.
Bug: UI Bug - New tab button not aligned with tabs
Status: NEW
Priority: --
Created: 2021-06-02 14:00:45+00:00
Resolved: 2021-06-03 16:00:39+00:00

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

Steps to reproduce:

Hover on the new tab button.


Actual results:

Highlighted button not aligned with the tab on the left. Both in light & dark mode.


Expected results:

Pixel perfect aligned.