av9ash/GitBugs huggingface dataset:
Bug: History and Synced tabs sidebars move the keyboard focus when the panel is opened
Status: NEW
Priority: P2
Created: 2024-10-15 01:46:44+00:00
Resolved: 2024-10-15 13:42:30+00:00

### STR:
1. In Firefox, ensure the `sidebar.revamp` pref is set to `true` and the new sidebar is visible
2. Locate and focus with keyboard a `History` panel switcher on the sidebar
3. Press `Enter` to open the History panel view and observe the focus behavior
5. Repeat previous steps on the `Tabs from other devices` panel as well
5. Repeat previous steps on the `GenAI` panel as well

### Expected:
1. The keyboard focus behaves consistently and is predictable when a sidebar panel switcher is activated and new panel is opened
    1. The keyboard focus may stay on the sidebar switcher panel, so a keyboard-only user would be able to continue switching the panel views without the need to navigate backwards multiple times.

### Actual:
1. For the `History` and `Tabs from other devices` panel, the focus is placed at the search input - while it does create quick access to the search functionality, the new sidebar has more controls that are not related to this newly opened panel view and users, for instance, when trying to review different views, would have to return to the sidebar itself from the panel every time. This also creates inconsistencies with other panels.
2. For the `GenAI` panel, the focus remains on the panel switcher (expected behavior for toolbars). Similar is the Settings panel view.

This is an [access-S3 issue](https://wiki.mozilla.org/Accessibility/Triage) because it provides an inconsiderate keyboard focus behavior and makes keyboard operation of the sidebar inconsistent and hard to predict.
Bug: Sidebar panels toggle buttons lack programmatic state
Status: NEW
Priority: P2
Created: 2024-10-15 01:58:27+00:00
Resolved: 2024-10-15 13:39:17+00:00

### Prerequisites:
1. Ensure a screen reader is running, i.e. NVDA on WinOS

### STR:
1. In Firefox, ensure the `sidebar.revamp` pref is set to `true` and the new sidebar is visible
2. Locate and focus with keyboard a `GenAI` panel switcher on the sidebar and observe the screen reader announcement
3. Press `Enter` to open the panel view and observe the screen reader announcement
5. Repeat previous steps on the `Tabs from other devices` panel as well
5. Repeat previous steps on the `History` panel as well

### Expected:
1. Each button that opens a sidebar's panel view has clear state that is being announced by default to indicate that this button does, in fact, control another part of the UI, and, especially, it is being announced when this state is changed because a sidebar panel switcher is activated and new panel is opened (i.e. [aria-pressed](https://w3c.github.io/aria/#aria-pressed) or [aria-expanded](https://w3c.github.io/aria/#aria-expanded) for buttons)

### Actual:
1. No state is provided for sidebar buttons that open panel views. When a view is expanded, the change of state is also not announced - the screenshot is after the GenAI sidebar was opened only the label and name are announced and no state

This is an [access-S3 issue](https://wiki.mozilla.org/Accessibility/Triage) because it relies on assistive technology users to guess what these buttons do, which state they are at, and what would happen, if a button is, in fact, pressed.
Bug: Sidebar lacks descriptive accessible name
Status: NEW
Priority: P2
Created: 2024-10-15 02:05:46+00:00
Resolved: 2024-10-17 14:30:15+00:00

### Prerequisites:
1. Ensure a screen reader is running, i.e. NVDA on WinOS

### STR:
1. In Firefox, ensure the `sidebar.revamp` pref is set to `true` and the new sidebar is visible
2. Locate and focus with keyboard any panel switcher on the sidebar and observe the screen reader announcement

### Expected:
1. The sidebar has descriptive accessible name, for instance, the horizontal tabs tool bar is labeled as `Browser tabs` (it is in a `tab control` container)

### Actual:
1. The sidebar is announced as `tab control` which makes it hard to differentiate from the general toolbar of the browser, where the horizontal tabs are. Especially, when both `tab control` panels are present.

This is an [access-S3 issue](https://wiki.mozilla.org/Accessibility/Triage) because it misses an opportunity to guide a screen reader user to what the purpose of this grouping is and how it is different from another `tab control`.
Bug: When any sidebar panel is closed, the keyboard focus moves to the webcontent
Status: NEW
Priority: P2
Created: 2024-10-15 02:14:04+00:00
Resolved: 2025-02-25 22:31:18+00:00

### STR:
1. In Firefox, ensure the `sidebar.revamp` pref is set to `true` and the new sidebar is visible
2. Locate and activate any panel view, i.e. `History`
3. Locate and focus the `X` Close button on the panel
3. Press `Enter` to close the panel view and observe the focus behavior

### Expected:
1. The keyboard focus is predictable when a panel is closed and it is returned to the sidebar to ensure users are not left wondering if they have missed anything (because the focus switched to another landmark and it's not clear if anything is between it and the sidebar) and that they could easily proceed with opening another sidebar panel, or navigate to the webcontent, if they choose to do so:
    1. The keyboard focus could return to the button that opened the same panel (i.e. when the panel was closed as a mistake, it could be easily reopened) - preferred.
    2. The keyboard focus could return to the last focusable element of the sidebar (the settings panel toggle button).

### Actual:
1. When a panel is closed with `X` button, the focus is placed at the webcontent.

This is an [access-S3 issue](https://wiki.mozilla.org/Accessibility/Triage) because it provides an inconsiderate keyboard focus behavior and makes keyboard operation of the sidebar hard to predict.
Bug: Visibility issues with install dialog “Cancel” button and optional permissions dialog “Deny” button when HCM is enabled
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-10-15 08:37:37+00:00
Resolved: 2024-10-18 08:56:49+00:00

Description:
When HCM is enabled in Windows and using the default HCM color schemes provided in the OS, there are several visibility issues with the install dialog “Cancel” button and the optional permissions dialog “Deny” button, as follow:
1. Using “High Contrast 1” and “High Contrast 2”, both the “Cancel” and “Deny” button strings are no longer visible when hovering the mouse over them, as these HCM color schemes both use white to highlight those buttons and the strings on the buttons are also white.
2. Using “High Contrast Black”, the buttons highlight is not visible when hovering over the buttons, as this HCM scheme uses black for highlighting and the dialog background is also black. The string on the buttons is still visible.
3. Using “High Contrast White”, the buttons highlight is not visible when hovering over the buttons, as this HCM scheme uses white for highlighting and the dialog background is also white. The string on the buttons is still visible.

This does not appear to be an issue introduced by the changes to the install and optional permissions dialogs, however due to work on these dialogs being in progress, this issue could be addressed.

For more details, see the attached screenshots.

Steps to reproduce:
A.
1. Enable “High Contrast 1” in the HCM settings pane
2. Install “Tree Style Tab”
3. On the install dialog, hover over the “Cancel” button (notice the button string is no longer visible)
4. Click on the add-on card in about:addons
5. Once in the detailed view of the add-on, click on the “Options” tab
6. Locate the “Context Menu” header
7. Click on the checkbox of “Allow to read and create bookmarks”. This will trigger the optional permissions dialog
8. On the optional permissions dialog, hover over the “Deny” button (notice the button string is no longer visible)

B.
1. Enable “High Contrast 2” in the HCM settings pane
2. Repeat Steps 2 & 3 from A. (notice the button string is no longer visible)
3. Repeat Steps 4 to 8 from A. (notice the button string is no longer visible)

C. 
1. Enable “High Contrast Black” in the HCM settings pane
2. Repeat Steps 2 & 3 from A. (notice the button highlight is not visible as it’s the same color as the background)
3. Repeat Steps 4 to 8 from A. (notice the button highlight is not visible as it’s the same color as the background)

D.
1. Enable “High Contrast White” in the HCM settings pane
2. Repeat Steps 2 & 3 from A. (notice the button highlight is not visible as it’s the same color as the background)
3. Repeat Steps 4 to 8 from A. (notice the button highlight is not visible as it’s the same color as the background)

Expected:
Button strings and highlights on hover should be visible with HCM enabled

Actual:
There are visibility issues with the mentioned button strings and highlights when HCM is enabled.
Bug: Urlbar doesn't show anymore partial origin in small windows with Scotch Bonnet unified search button
Status: RESOLVED
Priority: P2
Resolution: INVALID
Created: 2024-10-15 09:02:56+00:00
Resolved: 2024-10-18 12:24:20+00:00

In a small window the urlbar used to at least partially show the origin, though now that space has been taken by the Unified Search button.

We could:
1. increase window min width
2. hide the button if the urlbar width goes below a certain threshold (it's not particurlarly usable there anyway)

The Sidebar Revamp team is likely looking at the former, though we may still want to do the latter.
Bug: Contextual Search should show configuration engines that arent enabled
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-10-15 09:50:18+00:00
Resolved: 2024-12-20 10:33:17+00:00

With Contextual Seach enabled visit https://www.ecosia.org/ and perform a search via the contextual search button, the resulting url should be identical to as if we had used the dedicated search button
Bug: [Experiment] Unenrolling from any "sidebar + GenAI" experiment does not revert the experience to the default one
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-10-15 11:13:05+00:00
Resolved: 2024-10-15 12:29:45+00:00

**[Affected versions]:**
- Firefox Nightly 133.0a1 - Build ID: 20241014095457
- Firefox Beta 132.0b7 - Build ID: 20241014091808 

**[Affected Platforms]:**
- Windows 10
- macOS 13.4
- Linux Mint 20.1

**[Prerequisites]:**
- Have following prefs set:
  - browser.search.region = US
  - nimbus.debug = true

**[Steps to reproduce]:**
1. Open the browser using the profile from the prerequisites.
2. Navigate to the following custom link to force enroll in the treatment-a of the experiment: `about:studies?optin_slug=new-users-sidebar-genai&optin_branch=treatment-a&optin_collection=nimbus-preview`.
3. Close the tab.
4. Navigate to about:studies.
5. Click the "Remove" button next to the "New users: sidebar + GenAI" experiment.
6. Observe the behavior. 

**[Expected result]:**
- The profile is unenroll from the experiment, and the sidebar and the new tab layout are reset to the old view which is the default.

**[Actual result]:**
- The profile is unenroll from the experiment, but the new sidebar and new vertical tab layout remain enabled. 

**[ Notes]:**
- The issue is also reproducible after a browser restart.
- The issue is also reproducible if naturally enroll in the experiment.
- The issue is also reproducible for the existing users experiment.
- Attached is a screen recording of the issue.
Bug: Rakuten search provider shows 404 error
Status: NEW
Priority: P1
Created: 2024-10-15 11:28:54+00:00
Resolved: 2024-10-15 14:02:51+00:00

When using built-in Rakuten search provider in Firefox ja-JP, it shows 404 not found page.  I think that Rakuten changes search URL (I don't know new URL, so we should contact to them for it).

This issue is both desktop and mobile.
Bug: empty about:logins screen
Status: NEW
Priority: --
Created: 2024-10-15 12:02:46+00:00
Resolved: 2024-11-04 16:09:59+00:00

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

Steps to reproduce:

Opened a newly Upgraded Firefox to 132.0b7 (64-bit)
Opened hamburger menu and clicked on passwords


Actual results:

First time after opening firefox, it only shows list of passwords and right section of page is emmty, clicking on any of passwords in list, screen goes empty. Refreshing the page will clear the password list too and consequent opening about:logins will just show an empty page until firefox is restarted to just show the list again


There is an error shows in console which is saying 

"Error: Firefox Accounts server must use HTTPS" 
FxAccountsConfig.sys.mjs:151:13

It also shows again on refreshing the about:logins screen. This also shows on opening about:logins page.

Note that passwords are still there and can be used in website, exported, cleared and imported again but just cannot see them probably due to error mentioned above!


Expected results:

Should show list of passwords, clicking on any password should show its details too
Bug: Firefox fails to assign to itself the default opening of file type AV1 Image File (AVIF)
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-10-15 13:58:38+00:00
Resolved: 2024-10-22 17:24:29+00:00

Hello. While Firefox has been set **in Firefox**, in the `about:preferences` page as the current browser by default, and that in this same page, in the _Files and applications_ | _Applications_ section, the content type _AV1 Image File (AVIF)_ has the corresponding action _Open in Firefox_, in Windows 11 v. 24H2, in _Windows Settings_ > _Apps_ > _Default apps_, the respective file _.avif_ is shown as being assigned to _Windows System Launcher_, thus indicating that Firefox fails to assign to itself the opening. For information, there, the option to open with Firefox exists and can be applied if desired.
Bug: about:preferences shortcut key only working after opening a menu
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2024-10-15 15:01:33+00:00
Resolved: 2025-01-28 14:39:00+00:00

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

Steps to reproduce:

Visit about:preferences and press (for example) "m" on the keyboard to open the "Import Data" setting


Actual results:

nothing. Only after you click the button and close the menu, you can press "m" to open it


Expected results:

It should open without the step that requires manually opening a menu first
Bug: Intermittent Wayland browser/components/backup/tests/marionette/test_backup.py | marionette_driver.errors.ScriptTimeoutException: Timed out after 30000 ms
Status: NEW
Priority: P5
Created: 2024-10-15 15:31:13+00:00
Resolved: 2024-11-11 06:20:13+00:00

**Filed by:** hskupin [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=478329808&repo=try
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/NBfsHKb2TnWtuVPB65icDw/runs/0/artifacts/public/logs/live_backing.log

---
```

```
Bug: PDF.js font rendering with self-intersecting glyphes
Status: RESOLVED
Priority: P3
Resolution: WONTFIX
Created: 2024-10-15 17:42:54+00:00
Resolved: 2024-10-27 13:26:20+00:00

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

Steps to reproduce:

Open test.pdf in PDF.js





Actual results:

The font 'Jost' (https://fonts.google.com/specimen/Jost) as well as others are not displayed correctly due to the way they are constructed which firefox does not handle. 



Expected results:

Font should be displayed correctly without holes.
Bug: When using compose key, pressing Ctrl or Shift will cancel compose mode and won't allow some combinations (Developer Edition 132.0b7)
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-10-15 18:36:41+00:00
Resolved: 2024-10-15 18:53:44+00:00

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

Steps to reproduce:

Press Compose Key, then Shift, then any other combination of keys.


Actual results:

Compose key input ends immediately and following inputs aren't added to the compose key buffer.


Expected results:

I should be able to press another key and finish my compose key input combination.
Bug: pageActionInUrlbar trigger doesn't have the right wait for ASRouter
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2024-10-15 19:03:18+00:00
Resolved: 2024-10-25 15:58:37+00:00

[See here](https://searchfox.org/mozilla-central/rev/754074e05178e017ef6c3d8e30428ffa8f1b794d/browser/modules/PageActions.sys.mjs#440):

```js
await lazy.ASRouter.initialized;
```

This property is actually just a boolean. The one we actually want to await is `ASRouter.waitForInitialized`. Alternatively, we might want to just change this to a boolean check `if (lazy.ASRouter.initialized) ...` but I'm not sure about that. I'd leave it up to the engineer who works on this.

This isn't currently causing any problems, but the code is technically wrong. So I'd recommend P3 priority, S4 severity.
Bug: New Tab Button Moves When Restarting Browser
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-10-15 21:17:47+00:00
Resolved: 2024-10-16 08:46:21+00:00

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

Steps to reproduce:

The New Tab button moves itself to the left side of my tabs every time I restart the browser. I prefer it on the right and am customizing my toolbar on every start up, and the button remains there for a session but once I restart it moves back to the left side. 

This started happening after a recent update messed up my toolbar customization in general, the bookmarks toolbar was showing but empty and some of the buttons got moved around. Though I was able to resolve most of this just by reediting my toolbar the New Tab button really wants to be on the left. 



Actual results:

The New Tab button is moving itself to the left of tabs out of set customized position to the right side of the tabs on browser startup. 


Expected results:

The New Tab button does not move lol
Bug: browser_multiselect_tabs_drag_to_bookmarks_toolbar.js should remove bookmarks added during the test
Status: NEW
Priority: P3
Created: 2024-10-16 01:42:17+00:00
Resolved: 2024-10-16 01:42:17+00:00

discovered by https://phabricator.services.mozilla.com/D225723

[browser/components/tabbrowser/test/browser/tabs/browser_multiselect_tabs_drag_to_bookmarks_toolbar.js](https://searchfox.org/mozilla-central/source/browser/components/tabbrowser/test/browser/tabs/browser_multiselect_tabs_drag_to_bookmarks_toolbar.js) creates bookmarks inside the bookmark toolbar, but it doesn't remove those bookmarks.
It should remove them, to avoid affecting other testcases.
Bug: Sentences ending with unicode full-stop "。" are wrongly recognized as a Domain Name.
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2024-10-16 03:43:30+00:00
Resolved: 2024-12-24 12:19:26+00:00

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

Steps to reproduce:

Search for two or more sentences without spaces with the address bar.

Such as:
- 見つかりません。名前を変更されたか、移動や削除が行われた可能性があります。
- はい。はい。
- yes.yes.

It could happen especially when searching for some error messages in Japanese or maybe Chinese language, which doesn't have spaces between words or sentences.


Actual results:

Firefox recognizes such sentences as domain names and then mostly returns with NS_ERROR_UNKNOWN_HOST.


Expected results:

Returns search result. (like Google search)

I don't know if there are some useful cases for such behavior though, Firefox should take such sentences as normal keywords. At least I want to have an option to ignore such active domain recognition.
Bug: Selecting Text in the Address Bar Has Weird Behavior
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-10-16 07:45:11+00:00
Resolved: 2024-10-16 09:55:58+00:00

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

Steps to reproduce:

1. select the entire text in the address bar (Ctrl + A or just a simple click)
2. shrink the selection by a word by Ctrl + Shift + ←


Actual results:

The selection shrinks by a single word for a brief moment (maybe shorter than 100ms) and then the selection gets reset with the cursor at the beginning.

Shrinking the selection by a character (Shift + ←) works fine.

I'm on Linux with Plasma desktop (Wayland), but it persists on Windows 11 too.
I CANNOT reproduce it on macOS; ⇧ + ⌥ + ← works properly.


Expected results:

The selection shrinks by a single word
Bug: Top 1 pixel missing from window
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-10-16 08:19:47+00:00
Resolved: 2024-10-21 10:38:49+00:00

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

Steps to reproduce:

Start firefox


Actual results:

All is fine, but top pixels (of outer firefox window) is missing.
This looks bad.


Expected results:

The top line schould be there. 
I found a similar issue for firefox 89 here: https://bugzilla.mozilla.org/show_bug.cgi?id=1707671
Bug: Input field cannot type with non-english as default keyboard with creating new bookmark folder
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2024-10-16 09:13:37+00:00
Resolved: 2024-11-18 12:38:16+00:00

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

Steps to reproduce:

System: macOS 14.5 Sonoma
Firefox: 131.0.3

0. Ensure that system have 2 keyboard inputs language (ex. Chinese + English), then make the non-English one active
1. Open "Bookmarks" > "Manage bookmarks" from the menu bar
2. Right-click on "Bookmarks Toolbar", then select "Add folder..."
3. The input prompt of naming the folder will show up


Actual results:

After the input prompt shows up, it cannot type in any characters instead changing the active keyboard input to "English".


Expected results:

It should take even the English characters as input when Chinese keyboard input is actived along the "CAP" is set, and also accept the Chinese input if "CAP" is non-set.
Bug: When same CSS class is set more than once, the extra class names are removed on hover
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-10-16 09:53:24+00:00
Resolved: 2024-10-18 12:39:28+00:00

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

Steps to reproduce:

I ran into this issue when developing a website with SemanticUI. A table cell had its class attribute set to "right aligned bottom aligned". The SemanticUI stylesheet contains the following rule:

.ui.table [class*="bottom aligned"]

Can also be reproduced by setting the class attribute to something like "test something test" on any element (for example the body)


Actual results:

When hovering the element, the extra redundant classname was removed from the element, resulting in above CSS rule not working any more.


Expected results:

The class attribute should remain unchanged
Bug: Double-click on the Tab Toolbar won't create new tab /131.0.2 snap
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2024-10-16 09:57:17+00:00
Resolved: 2024-10-21 09:05:28+00:00

Hi,

Can we restore the original : double click on tab bar creates a new tab instead of resizing?
Why?
 -I think that most of us create new tab more than they resize their windows.
-This would also remove the confusion one may have when using middle click in the tab bar : 
Middle click on a tab shutdowns a tab
Middle click on tab bar empty space opens a tab

Kind regards,

131.0.2 snap version on Kubuntu 24.10, kde 6.15