av9ash/GitBugs huggingface dataset:
Bug: Translations panel does not receive keyboard focus when activated with Enter/Space
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2023-05-26 17:29:59+00:00
Resolved: 2023-11-17 15:54:55+00:00

### STR:
1. Ensure that Translations are activated via `browser.translations.enable=true`.
1. On a translatable website, navigate to the awesomebar. Press `Tab` once to move the focus to PiP control (if present) and then (if needed) use `Right Arrow` key to focus the `Translate this page` toggle
1. Press `Space` or `Enter` to open a Translations panel
1. When the panel is opened, locate the keyboard focus position

### Expected:
1. The focus is moved to the panel and the gear image button (`Manage translation settings`) is focused

### Actual:
1. The keyboard focus remains on the toggle button. Screen reader user may not be aware of the panel being opened (i.e. an NVDA screen reader on Windows does not announce anything)

### Notes:
1. pressing `Tab` once or pressing `Down Arrow` key would move the focus to the panel, thus the panel could be reached by a keyboard-only user, but this is a workaround and not an expected behavior, thus an a11y-S3 severity
2. Good example: Identity panel toggle (`View site information`)
Bug: Translations panel includes a Translate to combobox that misses programmatic label
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2023-05-26 18:24:40+00:00
Resolved: 2023-11-17 15:54:55+00:00

### STR:
1. Ensure a screen reader is running
1. Ensure Translations are activated via `browser.translations.enable=true`
1. On a translatable website, navigate to the awesomebar. Press `Tab` once to move the focus to PiP control (if present) and then (if needed) use `Right Arrow` key to focus the `Translate this page` toggle
1. Press `Space` or `Enter` to open a Translations panel. Until the bug 1835361 is not resolved, press `Tab` to move the focus to the Translations settings button
1. Press `Tab` once again to move the focus to the combobox with available language options.
1. Observe the announcement that a screen reader makes

### Expected:
1. The combobox is announced its visual label (`Translate to`) as well as the preselected option: `Translate to, {English}`

### Actual:
1. The combobox is only announcing its preselected option, while ignoring its on-screen label (`Translate to`) and only mentions the language: `{English}`
Bug: Containers settings should explain that containers are not available in private windows (including permanent private browsing mode)
Status: NEW
Priority: P5
Created: 2023-05-26 18:39:53+00:00
Resolved: 2024-02-28 12:23:38+00:00

STR
- start in PB mode, and/or have containers disabled
- go to `about:preferences#privacy` - note no containers UI
- go to `about:preferences#containers` - containers UI is available

This is causing some confusion for Tor Browser and Mullvad Browser users.
Bug: Translations panel toggle does not communicate its collapsed/expanded state
Status: RESOLVED
Priority: P3
Resolution: INVALID
Created: 2023-05-26 19:34:46+00:00
Resolved: 2023-11-17 15:54:55+00:00

### STR:
1. Ensure a screen reader is running
1. Ensure that Translations are activated via `browser.translations.enable=true`.
1. On a translatable website, navigate to the awesomebar. Press `Tab` once to move the focus to PiP control (if present) and then (if needed) use `Right Arrow` key to focus the `Translate this page` toggle
1. Observe a screen reader announcement
1. Press `Space` or `Enter` to open a Translations panel
1. Observe a screen reader announcement
1. (While the bug 1835361 is not resolved) move the focus away from the toggle and back by pressing `Shift + Tab` and then `Tab`
1. Observe a screen reader announcement
1. Press `Escape` to dismiss the panel
1. Focus the toggle button and observe a screen reader announcement

### Expected:
1. The `Translate this page` button would, by default, when the panel is not visible, announce `collapsed` as its state and when opened the state would dynamically change to `expanded` and back to `collapsed`, when the panel is dismissed

### Actual:
1. Screen reader is not announcing if the toggle button `Translate this page` has a popup panel attached or not (`collapsed` state would imply this to a user), and whether the panel itself is visible or not (`expanded`/`collapsed` states)

### Notes:
1. Use `aria-expanded` set to `false` by default on the button element and update its value appropriately
Bug: Keep focus on the Translate This Page button after a Show Original option is activated
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2023-05-26 19:48:09+00:00
Resolved: 2023-11-17 15:54:55+00:00

### STR:
1. Ensure that Translations are activated via `browser.translations.enable=true`.
1. On a translatable website, navigate to the awesomebar. Press `Tab` once to move the focus to PiP control (if present) and then (if needed) use `Right Arrow` key to focus the `Translate this page` toggle
1. Press `Space` or `Enter` to open a Translations panel
1. Select a language, navigate to and activate `Translate` button
1. Confirm the keyboard focus remained on the Translate This Page toggle button
1. Press `Enter` or `Space` to activate the Translations panel again
1. Navigate to and activate `Show original` button
1. When the original language of the page is loaded, locate the keyboard focus position

### Expected:
1. The focus remained on the `Translate this page` toggle button

### Actual:
1. The keyboard focus is moved to the browser window itself and it is not visible. User has to press `Tab` to locate the focus (which would land on a Fx View control) and then tediously continue pressing `Tab` to return to the control that they just used on the toolbar panel of the browser window.
Bug: Translations panel toggle does not clearly communicate its pressed/active state
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2023-05-26 20:02:54+00:00
Resolved: 2023-11-17 15:54:55+00:00

### STR:
1. Ensure a screen reader is running
1. Ensure that Translations are activated via `browser.translations.enable=true`.
1. On a translatable website, navigate to the awesomebar. Press `Tab` once to move the focus to PiP control (if present) and then (if needed) use `Right Arrow` key to focus the `Translate this page` toggle
1. Observe a screen reader announcement
1. Press `Space` or `Enter` to open a Translations panel
1. Select a language, navigate to and activate `Translate` button
1. Confirm the keyboard focus remained on the `Translate This Page` toggle button and observe a screen reader announcement of this control

### Expected:
1. Because the on-screen status of the `Translate this page` button was changed, it would also announce that it is `pressed`.  A label of the toggle button is prepended with `{en}` to indicate currently selected language

### Actual:
1. A label of the toggle button is prepended with `{en}` to indicate currently selected language, but it may be too subtle for some screen reader users especially those with cognitive difficulties, with dyslexia. Screen reader is not announcing if the toggle button `Translate this page` is pressed/active thus it may be not clear to a user if the translation was performed for this page.

### Notes:
1. This is not a failure of technical guidelines for a11y, as the label includes the on-screen language indication, yet the experience may be made more delightful for screen reader users, especially because the language chosen is used in a short version which may be missed by some users with cognitive difficulties.
1. Use `aria-pressed` set to `false` by default on the button element and update its value appropriately.
Bug: "Search bookmarks/history" menu item should be hidden/disabled when a user has explicitly disabled the Bookmarks/History search shortcuts
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2023-05-27 10:11:49+00:00
Resolved: 2023-06-13 13:20:41+00:00

Prerequsites:
1. Right-click on the navigation bar and select _Customize Toolbar_.
2. Add the _Bookmarks menu_, _History_, and _Library_ buttons to the navigation bar.
3. Open `about:preferences#search` and unselect both the _Bookmarks_ and _History_ search shortcut.

STR:

Click on the "Search bookmarks/history" menu item in _Bookmarks menu/History/Library_.

Expected Behavior:

"Search bookmarks/history" menu item is hidden/disabled when a user has explicitly disabled the _Bookmarks/History_ search shortcuts in `about:preferences#search`.

Actual Behavior:

"Search bookmarks/history" menu item persists even when a user has explicitly disabled the _Bookmarks/History_ search shortcuts in `about:preferences#search`. Clicking on the option causes Firefox to close the menu and hand off the search to the urlbar.

Mozregression returned

Last good revision: 2100122222770e5ac136a7296a0b7aac071f4965
First bad revision: 48c487e6d15ec28f0b845fa441ec13b46a1b2d98
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2100122222770e5ac136a7296a0b7aac071f4965&tochange=48c487e6d15ec28f0b845fa441ec13b46a1b2d98

for the "Search bookmarks" option, and 

Last good revision: ab69eb7e83f9cd078961372186b062a1852648bc
First bad revision: 863228beb272fd4b9efd7788cdda52cb9c0b9919
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ab69eb7e83f9cd078961372186b062a1852648bc&tochange=863228beb272fd4b9efd7788cdda52cb9c0b9919

for the "Search history" option.

At first I thought this is at least going to allow me to search within the menu itself, but no it just hands off the whole thing to the urlbar like the New Tab Page does (at least I can still disable that via `browser.newtabpage.activity-stream.improvesearch.handoffToAwesomebar`). It's funny to see that one of the screenshots in the original bug report referring to the search bar in the Bookmarks/History sidebar, because _THAT_ one actually allows you to search bookmarks/history without being limited by `browser.urlbar.maxRichResults` (by default 10) and subjected to whatever freceny weights there were. And it was there from the beginning!

It's ironic this was implemented as an "enhancement", considering that UX doesn't even want users to _use_ navigation bar buttons by default (bug 1692214?). "Writing a SUMO article" and directing users to use the sidebar would have been a better idea IMO.

Also see bug 1657790 comment 3 for a somewhat-related discussion.
Bug: Focused pane selection color in the Library is now too bright on Windows
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2023-05-27 10:16:37+00:00
Resolved: 2023-05-31 17:31:47+00:00

Tested on 113.0.2.

STR:

1. Open the Library.
2. Notice the color for the selected item(s).

Expected Behavior:

Focused pane selection color in the Library uses whatever color Windows 7/10 uses in the File Explorer, even after migrating to non-native themes (not that they do so in Proton but hey).

Actual Behavior:
Focused pane selection color in the Library is now so bright that it actually makes the gray color looks good. It's not _as_ bad with the proton teal color in dark mode but then you get teal background against black text, which is also pretty bad to be honest. For some reason the same color (in both light/dark themes) looks much more tolerable when I am selecting multiple items in the Library.


Mozregression returned

Last good revision: b043e43853792ed5a7e690651119ab8eed370e7f
First bad revision: 9361e4b16e0b9742b2922590a963a6b416134ed5
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b043e43853792ed5a7e690651119ab8eed370e7f&tochange=9361e4b16e0b9742b2922590a963a6b416134ed5


Examples of more a reasonable color in light themes would be the color you get when highlighting text with a cursor on hg and phabricator. I would also argue that for dark themes, the focused pane selection color should be changed to teal background against _white text_, similar to how text were highlighted when using the `Find in Page` option.

I would also like to point out that bug 1717260 actually does not affect linux builds, even in the case of ESR 102. And that's probably because _someone_ took the time and effort in making it look nice, which I really doubt will survive when someone else decided to do another UI overhaul.

If there's no intention to improving this further, can we at least consider backing this out until after ESR 115 (where Win7 support ends) landed? Personally I would rather live with gray then a color too bright.
Bug: Opening multiple favorites at a time
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2023-05-28 01:09:12+00:00
Resolved: 2023-07-24 07:06:23+00:00

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

Steps to reproduce:

I open favorites to a bunch of sites at by clicking on each one.  Normally it is smooth and no issues.  With 113.0.2 it seems to have trouble processing them and misses some of the clicks to open.  It also seems to freeze processing when you click on a favorite.  So if I am opening say 10 favorites in rapid succession it might only open 7 tabs missing 3 of the clicks.


Actual results:

Opening say 10 favorites in rapid succession it might only open 7 tabs missing 3 of the clicks.


Expected results:

Normally before 113.0.2 it was smooth and did not freeze when clicking on the favorites in rapid succession and opened them all with out a problem.
Bug: Firefox 113.02 (Windows x64) does not open.
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-05-28 14:45:22+00:00
Resolved: 2023-07-05 15:04:59+00:00

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

Steps to reproduce:

I allowed the update to install and rebooted the app. 


Actual results:

The app begins to load but the home screen never appears. The layout (placement of icons, search bar) of the browser is different, as well. The app appears to be buffering. Without prompting, a New Tab appears, but it is blank.


Expected results:

The app should have booted fully and loaded the home page I entered in settings. Presumably, the layout (icon placement, search bar) should be the same as before, but I can't be sure.
Bug: search engine shortcut activates after browser restart
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-05-28 21:10:06+00:00
Resolved: 2023-06-12 16:26:42+00:00

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

Steps to reproduce:

1. disable "Wikipedia (en)" in "Search Shortcuts" at about:preferences#search
2. switch to any other browser language
3. switch back to english
4. close Firefox
5. start Firefox, visit "Search Shortcuts" at about:preferences#search again.


Actual results:

"Wikipedia (en)" was automatically reactivated.


Expected results:

Search Shortcuts in general should not reactivate at all when restarting Firefox with any Search Shortcut disabled.
Bug: [fluent] Missing message in locale en-US: update-manual aboutDialog.xhtml
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-05-28 22:45:35+00:00
Resolved: 2023-06-04 21:46:46+00:00

On Nightly, click the "About Nightly" dialog to check for updates. Then look at the Browser Console. It contains the following warnings:

> [fluent] Missing message in locale en-US: update-manual aboutDialog.xhtml
> [fluent] Couldn't find a message: update-manual aboutDialog.xhtml
> [dom/l10n] Could not complete initial document translation. aboutDialog.xhtml

It looks like the message was deleted in bug 1820654 but `update-manual` is used here and should be brought back:
https://searchfox.org/mozilla-central/rev/f4d3fe187cf7dffa4c13b354bbde9bc47b5ccd3f/browser/base/content/aboutDialog.xhtml#91
Bug: In Permissions tab of  Page Info dialog, No focus ring for checkbox and radio button when pressing [Tab] key and [→][←] keys
Status: RESOLVED
Priority: P1
Resolution: DUPLICATE
Created: 2023-05-29 04:59:38+00:00
Resolved: 2023-06-05 12:36:19+00:00

Steps To reproduce
1. Open any web page
2. Open Page Info dialog(Ctrl+I)
3. Switch to Permission tab
4. Press [Tab] key and and [→][←] keys to navigate item in the list

Actual Results:
No focus ring for checkbox and radio button.

Expected Results:
Focus ring for Checkbox and Radio button should appear.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=850a5972994c7eb9705be5c598c7f304b2354927&tochange=1cdfa0b182b14ab3b9dbbb7d7b582f2a887a484e
Bug: In Unknown Content type dialog, No focus ring for checkbox and radio button when pressing [Tab]  and  [→][←][↑][↓]  keys
Status: RESOLVED
Priority: P1
Resolution: DUPLICATE
Created: 2023-05-29 05:14:30+00:00
Resolved: 2023-06-05 12:36:28+00:00

Steps to reproduce:
1. about:preferences#general,  Enable `Ask whether to open or save files` and restart
2. Click some link to open (e.g. https://ftp.mozilla.org/pub/firefox/nightly/2005/02/2005-02-01-13-trunk/firefox-1.0+.en-US.win32.zip )
3. When open Unknown Content type dialog, press [Tab] keys  and  [→][←][↑][↓]  keys

Actual Results:
No focus ring for checkbox and radio button.

Expected Results:
Focus ring for Checkbox and Radio button should appear.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=850a5972994c7eb9705be5c598c7f304b2354927&tochange=1cdfa0b182b14ab3b9dbbb7d7b582f2a887a484e
Bug: Fx add-on suggestion is displayed in different section depending on keyword used
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-05-29 07:07:19+00:00
Resolved: 2023-06-09 14:58:19+00:00

**Found in**
* Fx 115.0a1

**Affected versions**
* Fx 115.0a1

**Affected platforms**
* Windows 10
* macOS
* Ubuntu 

**Precondintions**
browser.urlbar.addons.featureGate set to true
browser.urlbar.suggest.addons set to true
browser.urlbar.quicksuggest.enabled set to true
browser.urlbar.suggest.quicksuggest.nonsponsored set to true
browser.urlbar.quicksuggest.dataCollection.enabled set to true
browser.urlbar.merino.enabled set to true
browser.urlbar.merino.providers set to amo
browser.urlbar.bestMatch.enabled set to true
browser.search.region set to US

Have RS connected to stage branch.

**Steps to reproduce**
1. Launch Firefox.
2. In the address bar type: read aloud.
3. Delete the input from step 2 and in the address bar, type: tts.

**Expected result**
* Firefox add-on suggestion is displayed in the same section.

**Actual result**
* Suggestions are displayed in different sections of the address bar drop-down.
* Suggestion from step 2 is displayed in the Firefox Suggest section.
* Suggestion from step 3 is displayed in the Top Pick section.

**Regression range**
* Not a regression.

**Additional notes**
* Please see the attachment for more details.
Bug: [Intermittent] [Nightly] The Top Sites tiles are misaligned after restarting the browser while 2 Firefox windows are open in the same time
Status: NEW
Priority: --
Created: 2023-05-29 15:07:30+00:00
Resolved: 2024-02-27 13:53:51+00:00

**[Affected versions]:**
- Firefox Nightly 115.0a1 (Build ID: 20230529093707)

**[Affected Platforms]:**
- Windows 10 x64
- macOS 12.6.1
- Linux Ubuntu 20.04 x64

**[Prerequisites]:**
- Have a VPN client connected to a US server (for users located outside the US).

**[Steps to reproduce]:**
1. Open the browser from the prerequisites.
2. Open a new tab and make sure you have Sponsored Top Sites.
3. Restart the browser using the shortcuts (Ctrl+Shift+J then Ctrl+Alt+R).
4. Dismiss the Default browser message.
5. Press the Ctrl+N shortcut to open a New Firefox Window.
6. Restart the browser using the shortcuts (Ctrl+Shift+J then Ctrl+Alt+R).
7. Observe the Top Sites.

**[Expected result]:**
- All the Top Sites have the same alignment.

**[Actual result]:**
- The Sponsored Top Sites are misaligned.

**[Notes]:**
- I also noticed that dismissing Sponsored Top Sites will lead to empty tiles being [misaligned](https://drive.google.com/file/d/1ApSyuQ8DaG1wCziTfluzgkYUqzgffSWy/view?usp=sharing) as well.
- I was not able to reproduce this issue on the Beta and Release channels.
- Here is a [screen recording](https://drive.google.com/file/d/1iE4t7ZSZvAWwPLT0vlzZ7ITQUNkJf_Os/view?usp=sharing) with the issue.
Bug: [Accessibility] Some url bar buttons are not reachable on Ubuntu and Windows
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2023-05-29 15:46:45+00:00
Resolved: 2023-05-30 19:36:19+00:00

**Found in**
* 115.0a1 (2023-05-29) 

**Affected versions**
* 102.11.0esr, 114.0b9, 113.0, 115.0a1 (2023-05-29) 

**Tested platforms**
* Affected platforms: Ubuntu22.04, Win 10
* Unaffected  platforms:  MacOS 13

**Steps to reproduce**
1. Launch Firefox.
2. Open a site to have more buttons in the url bar (e.g https://www.reddit.com/ or www.whereby.com/olacreola).
3. Use Tab to reach each url bar button.

**Expected result**
* When you reach the first url bar button from each group (see the attached image), Screen reader should announce that there are more buttons in that group, or you should be able to reach them with tab.

**Actual result**
* Ubuntu 22.04, Win 10: the reached button is described, but the user is not informed there are more buttons in the same area (which are reachable by R-Arrow, not Tab).
* MacOs 13: Screen reader describes the button and lets you know it’s located inside a “toolbar item palete” and you can use Arrows to navigate further.

**Additional notes**
The group of buttons near the “Application menu” and those near the "Refresh" button are treated somewhat differently:
* Ubuntu 22.04: the other buttons are not announced.
* *Win 10: Screen reader announces there are more buttons: “Save to pocket button 1 of 3”
* MacOs 13: Screen reader describes the button and lets you know it’s located inside a “toolbar item palette”.

**Regression range** - not a regression

**Why is this important**
For (Win and Ubuntu) users having a visual disability is practically impossible to know url buttons like Camera and Mic Permission button exist and can be accessed in the url bar.
Bug: repeated issue with tab movement (unknown cause)
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2023-05-29 16:37:11+00:00
Resolved: 2023-08-30 09:28:26+00:00

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

Steps to reproduce:

i dont know, it just happened one day while i was going about my internet buisness


Actual results:

i keep stopping being able to move my tabs around. i can fix it temporarily by updating my computer, but yeah


Expected results:

i should be able to move my tabs around without updating my computer
Bug: "Search with Google" is hidden for Rich Entities entries when accessed by keyboard
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-05-29 19:16:56+00:00
Resolved: 2023-07-07 14:36:39+00:00

**Note**
* 

**Found in**
* 115.0a1 2023-05-29

**Affected versions**
* Nightly 115.0a1 2023-05-29

**Tested platforms**
* Affected platforms: Win 10 64-bit, OSX 10.14
* Unaffected platforms: -

**Preconditions**
* `browser.urlbar.richSuggestions.featureGate` set to true.
* Connect to stage-preview using RS devtools addon.
Run the following snippet in the Browser Console: `Services.prefs.getDefaultBranch("").setCharPref("browser.search.param.search_rich_suggestions", "fen")`

**Steps to reproduce**
1.  Type a popular keyword inside the Address Bar - Search suggestions are shown alongside Rich entities.
2. Navigate through the Rich suggestions list using TAB and Up/Down arrow keys.

**Expected result**
Rich entities are autofilled in the address bar, `Search with Google` is visible for each selection.

**Actual result**
`Search with Google` label is missing on keyboard selection, it is only visible on mouse hover.

**Regression range**
* Last good: 2023-05-22
* First bad: 2023-05-23
* Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5b6dc73ad880b4b0cff9756679675bd77c68a00b&tochange=4528705310aaf48f2821992409ddb444356112ff
* Potentially regressed by: bug 1832518