av9ash/GitBugs huggingface dataset:
Bug: since the latest update, my bookmarks toolbar has been empty. the bookmarks are in a file with all other bookmark files accessed from the menu bar, but won't show on bookmarks tool bar, i've tried everything, please fix this.
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-10-05 20:27:19+00:00
Resolved: 2024-10-06 05:42:51+00:00

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

Steps to reproduce:

restarted nightly (bookmarks toolbar still empty/blank), and tried to manually slide the bookmarks into the toolbar (still blank). restarted my pc, I've hidden the bookmarks toolbar,then restarted nightly and clicked ''always show'' (still blank)
i don't want to set it to default because it'll lose my bookmarks.


Actual results:

nothing happened, my bookmarks toolbar is still a big blank space.


Expected results:

My bookmarks toolbar should be filled with bookmarks and folders of bookmarks, so I can easily access whatever bookmark I need to open. 
my eyesight is poor, so the bookmarks toolbar is essential.
Bug: New tab button resets to left of bar
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-10-06 04:11:14+00:00
Resolved: 2024-10-06 05:43:24+00:00

The new tab button resets to the left of the tab bar every time the browser is opened. Moving it with "Customize Toolbar" works through the entire session, but if the browser is closed and reopened it resets to the original position.
Version: Firefox Developer Edition version 132.0b3 (64 bit)
OS: Windows 11 Home
Bug: Disabling "Show recent searches" doesn't work
Status: NEW
Priority: P3
Created: 2024-10-06 13:08:46+00:00
Resolved: 2024-10-14 15:14:55+00:00

Steps to reproduce:

- Disable "Show recent searches" in the settings
- Search for anything via the URL bar (Google is set as a default search engine in my case)
- Open new tab and begin searching for the same thing again


Actual results:

The last search appeared on top of the results, despite "Show recent searches" being disabled. Setting "browser.urlbar.maxHistoricalSearchSuggestions" via about:config to 0 prevents recent searches from being shown, but they are still being remembered, so when the value is restored to a higher number, old searches will still show up.


Expected results:

The recent search should not be displayed
Bug: the lounge keybindings do not work in nightly
Status: UNCONFIRMED
Priority: --
Created: 2024-10-06 19:19:50+00:00
Resolved: 2024-10-25 12:12:02+00:00

the lounge keybindings do not work in firefox 133 on aarch64 (raspberrypi 5). but they work fine on x86_64 in firefox 133. they were working fine on aarch64 in firefox 132. will gladly supply more info to the best of my abilities if asked.
Bug: Bookmarks toolbar showing blank, without my bookmarks
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-10-06 21:52:33+00:00
Resolved: 2024-10-07 05:38:41+00:00

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

Steps to reproduce:

This is in Firefox Developer Edition
I've tried:
* Hiding and showing the bookmarks toolbar
* Restarting Firefox
* Checking FIrefox is up to date (it is)
* Checking my bookmarks still exist (they do)
* Clicking on the blank toolbar where the bookmarks should be



Actual results:

The bookmarks toolbar hides and shows ok, but there are no bookmarks on it. Restarting firefox didn't help.
Clicking on the blank toolbar (where the toolbar should be) didn't do anything other than toggle between maximising and de-maximising the window. ie there don't seem to be any invisible bookmarks there to click on.


Expected results:

Bookmarks should display on the bookmarks toolbar.
Bug: Legacy sidebar splitter overaps urlbar suggestions
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-10-07 05:41:53+00:00
Resolved: 2024-11-15 13:56:31+00:00

STR:

1. press ctrl+h to open the history bar
2. press ctrl+l to open url bar suggestions

other side bars like tree-style-tab are also affected

regression bug found via mozregression
Bug: Long running high CPU on parent process, possibly zlib
Status: VERIFIED
Priority: --
Resolution: DUPLICATE
Created: 2024-10-07 05:59:53+00:00
Resolved: 2024-10-08 03:44:20+00:00

Running Firefox Nightly 133.0a1 (2024-10-06) on macOS sequoia 15.0.1 I'm experiencing frequent long running periods of high CPU on the parent process, resulting in an unresponsive browser.

Multiple times per hour I experience about 15 seconds of very slow to unresponsiveness, this impacts the chrome as well as content.  These slowdowns do not appear to be related to my activity in the browser; as such I don't have steps to reproduce.

However, I have two profiles: https://share.firefox.dev/3BAICNV and https://share.firefox.dev/480Li3l, both pointing at zlib.

This wasn't occurring last time I used this system which was two weeks ago; I updated both Firefox and macOS (from 15.0.0 to 15.0.1) this morning prior to actively using Nightly.
Bug: personal bar and address buttons have disappeared or shuffled
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-10-07 07:46:54+00:00
Resolved: 2024-10-07 09:24:38+00:00

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

Steps to reproduce:

Nothing, maybe just an update.
I should be on 132.0b2 with Firefow Developer Edition.


Actual results:

No more bookmarks on my personal bar below the address bar. It is now empty. My bookmarks are still in the manager.
And no more Refresh button, the previous and forward are on the right of the address and the module button is on the left. (all shuffled)
Finally, no more extensions buttons on the right of the address bar.
You can see the issue on the attached screenshot (the below one).


Expected results:

All my personal bookmarks below the address bar.
Previous, Forward and Refresh buttons on the left.
Other buttons (download, options...), modules and extensions buttons on the right.
You can see what I had before on the attached screenshot (the top one).
Bug: Weird behavior of the 'Translation' button in the address bar when the Persist Search button is enabled
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-10-07 08:00:49+00:00
Resolved: 2024-10-18 13:32:21+00:00

**Found in**
* Nightly 133.0a1

**Affected versions**
* Nightly 133.0a1


* Affected platforms:
*  Ubuntu 22
*  macOS 14
*  Windows 10


**Preconditions**
* Have browser.urlbar.scotchBonnet.enableOverride set to true.

**Steps to reproduce**
1.  Launch Firefox and perform a search using the each one of the default search engine (Google/DuckDuckGo/Bing).
2.  Click on the Show the address in the Location bar (Blue Globe icon) button.
3.  Observe the address bar.

**Expected result**
* Search term is replaced and the full url is shown.
* Bookmark Star is shown at the right of the address bar
* Translations button is shown if Fx default language does not match with the website localization.

**Actual result**
* Search term is replaced and the full url is shown.
* Bookmark Star is shown at the right of the address bar
* For DuckDuckGo and Bing the Translations button is missing from the address bar even if Fx default language does not match with the website localization.

**Regression range**
* Not a regression. 

**Additional notes**
*  Should the Translation button be always viewable next to the Globe button? Or should it be accessible via a shortcut just the like Bookmarks are (Cmd + D)?
Bug: New tab icon is gone on FF Dev 132.0b3
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-10-07 08:09:35+00:00
Resolved: 2024-10-07 10:48:04+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:

I updated Firefox Developer to version 132.0b3 and opened the browser.


Actual results:

The new tab icon is gone.


Expected results:

The icon should still be there...
Bug: Translation effects hidden fields in login forms, which may break them
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-10-07 08:14:57+00:00
Resolved: 2024-10-07 13:14:38+00:00

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

Steps to reproduce:

- Visit the login form of site which is in a language where translation was previously requested for. (Found with Roundcube if its Language is set to en_US, but FF is in German)
- Try to Login


Actual results:

The Login fails because Firefox Translates hidden meta information (input[type=hidden])/Information that is submitted with the POST Request, that Roundcube processes for the Login.


Expected results:

The page should be shown in the requested language without interfering with Meta-information of HTML Forms or the Translation of Form elements should be reverted when the Form is submitted.
Bug: installation.firstSeen.* scalars should not be recorded in all process types
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-10-07 08:22:58+00:00
Resolved: 2024-10-08 04:26:27+00:00

`installation.firstSeen.*` scalars are currently marked as being recorded in all process types. This will get in the way when migrating them to Glean as the Glean boolean metric is only supported on the parent process.
Bug: 4.38% tart (Windows) regression on Sat September 28 2024
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-10-07 08:34:18+00:00
Resolved: 2024-10-24 00:44:53+00:00

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

### Regressions:

| **Ratio** | **Test** | **Platform** | **Options** | **Absolute values (old vs new)** |  
|--|--|--|--|--| 
| [4%](https://treeherder.mozilla.org/perfherder/graphs?timerange=1209600&series=autoland,86450,1,1)  | [tart](https://firefox-source-docs.mozilla.org/testing/perfdocs/talos.html#tart)  | windows11-64-shippable-qr | e10s fission stylo webrender | 1.81 -> 1.89 | 


Details of the alert can be found in the [alert summary](https://treeherder.mozilla.org/perfherder/alerts?id=2283), 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 patch(es) may be backed out** in accordance with our [regression policy](https://www.mozilla.org/en-US/about/governance/policies/regressions/).

If you need the profiling jobs you can trigger them yourself from treeherder job view or ask a sheriff to do that for you.

You can run all of these tests on try with `./mach try perf --alert 2283`

The following [documentation link](https://firefox-source-docs.mozilla.org/testing/perfdocs/mach-try-perf.html#running-alert-tests) provides more information about this command.

For more information on performance sheriffing please see our [FAQ](https://wiki.mozilla.org/TestEngineering/Performance/FAQ).

If you have any questions, please do not hesitate to reach out to afinder@mozilla.com.
Bug: Middle-clicking the new tab button in the sidebar no longer performs action
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-10-07 09:02:23+00:00
Resolved: 2024-11-05 16:26:56+00:00

STR:
1. Start with `sidebar.verticalTabs = true` and `sidebar.revamp = true`.
2. Copy text into the clipboard.
3. Middle-click the new tab button in the sidebar.

Expected:
New adjacent tab is created (Windows) or search done in a new tab using clipboard contents (Linux).

Actual:
Nothing happens.

The new tab button in the titlebar/toolbar is unaffected.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a38ff75405d8540cb07b76bcf576ab87fe33a9bd&tochange=cd29dfbfb3d6a119425aa32eb5450b723baa1f22

Regressed by Bug 1912403.
Bug: Content top border missing with sidebar revamp since navigator toolbox z-index changed
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-10-07 09:14:44+00:00
Resolved: 2024-11-07 13:56:00+00:00

STR:
1. Start with `sidebar.revamp = true`.

Content top border missing regardless of theme or bookmarks toolbar visibility.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=c3a9b6795b2d67c054b596a170b3faa7af723e26&tochange=0ce46cb64bf09bfa7f0edd1340f7d7166fbbf8ec

Regressed by Bug 1922546.
Bug: "Private browsing" icon/label no longer shown in titlebar with vertical tabs
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-10-07 10:02:16+00:00
Resolved: 2024-11-15 14:11:58+00:00

STR:
1. Start with `sidebar.verticalTabs = true` and `sidebar.revamp = true`.
2. Enable Light/Dark theme that does not style private windows differently.
3. Create a private window.

Expected:
Some indication of private browsing in the titlebar.

Actual:
The "Private browsing" icon and label is missing.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b17f4d3142eeb0488513b984c8f5113e80101b96&tochange=82dacb5e3821fc0081deed13bd932839d65867e0

Regressed by Bug 1899598.
Bug: Blank toolbar and bookmarks-toolbar after update to 132b2 Developer Edition
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-10-07 10:57:41+00:00
Resolved: 2024-10-21 14:58:52+00:00

Steps to reproduce:

Upgrade Firefox Developer Edition. I think it was the update to 132b2 that triggered the issue.
It happened on all my three PCs (1x Windows 10, 2x Windows 11).

I'm also running Nightlies (though not as often as Beta Dev Editions), but haven't seen issue at any time in my Nightlies.

It looks like bug 1919721, but sounds like that should be fixed?
If same bug, will I have to manually repair or will it fix itself?


Actual results:

1) Toolbar icons disappeared. That is extensions I had pinned, plus Back, Forward, Reload, Home and New Tab icons.
2) Bookmark Toolbar became empty, however the bookmarks are still available via menu "Bookmarks"->"Bookmarks Toolbar"


Expected results:

An update without blanking my toolbars.
Bug: Tab Switcher Doesn't Work If List All Tabs is open
Status: UNCONFIRMED
Priority: P3
Created: 2024-10-07 11:05:51+00:00
Resolved: 2024-12-17 10:26:09+00:00

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

Steps to reproduce:

Click on show all tabs (chevron in top right corner) and keep it open
Press Ctrl+Tab to open the tab switcher and while holding ctrl press tab to move to the other tabs in the switcher



Actual results:

The tab switcher picks only the first tab (which is already open) and on hitting tab, it still highlights the first tab. On pressing SHIFT + TAB it focuses on »View all <n> tabs« button but remains focused on it despite hitting shift+tab again


Expected results:

The tab switcher should toggle to each of the recently open tabs when (shift) + tab is pressed
Bug: Scrolling up and down with scrollwheel no longer works properly, Wayland/Linux
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-10-07 11:34:01+00:00
Resolved: 2024-10-07 16:13:06+00:00

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

Steps to reproduce:

Visit a page with content that is too tall for the viewport, e.g. https://news.ycombinator.com

Use mouse wheel to try and scroll up and down.


Actual results:

Cannot scroll up and down for 99% of attempts. Sometimes it's possible to scroll a tiny amount, but it then stops working again.

Cursor keys still work.


Expected results:

Ability to scroll up and down
Bug: Toolbar buttons overlap in small windows with vertical tabs
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-10-07 12:03:10+00:00
Resolved: 2024-10-28 11:59:27+00:00

## STR

Running Nightly 133.0a1 (2024-10-06) with vertical Tabs enabled. 

On Mac, Windows, or Linux and there are various issues related to z-index at small screen widths. 

## What happens

Icons are running behind each other and on windows icons are visible in the addressbar. See screenshots for what happens on each platform.

## What should happen

Reduced widths should not cause icons to disappear behind other icons (e.g. the extensions icon) or be partly visible.
Bug: New Tab Wallpaper groups are not labeled
Status: NEW
Priority: P3
Created: 2024-10-07 13:31:21+00:00
Resolved: 2024-11-20 20:28:06+00:00

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

### STR: 
1. Open Firefox on the New Tab page
2. Navigate to the "Personalize New Tab" (gear icon) button and activate it
3. On the "Personalize New Tab" dialog, locate and navigate to either of wallpaper groups, i.e. to `Solid colors`, and observe the screen reader announcement

### Expected:
1. The wallpaper group section label that is visually present (the `Wallpapers` text) would be announced alongside the group role and the first focused option (i.e. `{Solid colors, radio button}, Wallpapers, group` for the Wallpapers group)

### Actual:
1. No group information is announced, only the currently focused option is being announced by a screen reader. The `<fieldset.category-list>` is included in the tree, but since there is no `<legend>` or `aria-label`/`aria-labelledby` is provided, it is skipped by NVDA altogether. 

### Remediation:
1. Add `aria-labelledby` to the `<fieldset>` and set it to reference the on-screen text `Wallpapers`.
Bug: New graphical issue after nightly update. the search bar dropdown text gets overwritten by the favourites bar text
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-10-07 13:34:37+00:00
Resolved: 2024-10-07 13:46:14+00:00

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

Steps to reproduce:

Installed last firefox nightly update. 
opened the firefox browser.
pressed ctr+t to open a new tab. 
started to type some text to search for a website and the bug/glitch happend


Actual results:

The "search results" of the topbar got overwritten by the favourite bar under it. Looks like a zlevel issue in css 


Expected results:

The favourite bar text under the dropdown shouldn't be visible.
Bug: Executing the same Drupal form post 1600 times with devtools open crashed Firefox Nightly tab.
Status: NEW
Priority: --
Created: 2024-10-07 13:58:32+00:00
Resolved: 2024-10-07 13:58:32+00:00

I triggered a crash with the signature 808f65c0-576a-4736-8f6e-7cbff0241007 and I figured I'd might as well explain what happened.
I had a drupal form with a lot of spam (as usual google captcha did nothing but increase tracking).  Irritatingly, drupal webforms has no built-in mass delete action.  I didn't feel like adding a module, so I whipped up a simple short script in the console that would click the delete and confirm buttons.  For sets where manual review was needed, I hit ctrl-enter in the console twice. Once to highlight the entry, and on 2nd run, to delete it.  It was fairly efficient.

 After eyeballing that the set of several thousand submissions I'd found definitely had no legit content, I decided review wasn't needed, so I'd just use xdotool to send 2 ctrl-enters.  I could probably have reworked it to just use 1 ctrl-enter with lags, but, it wasn't going to significantly change the process.  So I set xdotool to it.

I came back to a Firefox OOM crash on the tab.  This was mildly surprising to me since the deletion reloads the page.  So you wouldn't think that any leaks were related to Drupal's javascript.  Which made me think the leak was probably in Firefox.

I wonder if the dev tools log history got too big and had no clean way to handle this...

Since I do have a bunch more spam to run through, on the off-chance it's the gui rendering of the log in devtools, I'm going to try with every log category unchecked and an impossible filter string ☺
Bug: New Tab Wallpaper option group selection is not communicated visually
Status: NEW
Priority: P3
Created: 2024-10-07 14:10:45+00:00
Resolved: 2024-11-20 20:29:08+00:00

### STR: 
1. Open Firefox on the New Tab page
2. Navigate to the "Personalize New Tab" (gear icon) button and activate it
3. On the "Personalize New Tab" dialog, locate and navigate to either of wallpaper groups, i.e. to `Photographs`
4. Confirm the group control is focused with keyboard and Press `Space` or `Enter` key to activate the group (while the bug 1922664 is opened, mouse/touch would be needed)
5. Select any wallpaper option and return to the previous view
6. Confirm the general Personalize New Tab dialog is opened, locate the Wallpapers section and visually locate the selected group option
7. Using keyboard, navigate to the Wallpapers group and focus any unselected group option and observe the difference between the selected/checked and focused states of options

### Expected:
1. The selected/checked wallpaper group section is clearly visually distinguishable from others, unselected/default wallpaper group options.

### Actual:
1. Even though the selected wallpaper is applied to the main New Tab Page area, it is not clear from the Settings dialog: The selected/checked wallpaper group section visually is the same as others, unselected/default wallpaper group options
Bug: [HCM] New Tab Wallpaper controls lack proper styling on High Contrast themes
Status: NEW
Priority: P3
Created: 2024-10-07 14:23:27+00:00
Resolved: 2024-11-19 04:18:59+00:00

### Prerequisites: 
1. Ensure Windows High Contrast theme is activated (Steps to activate an OS High Contrast Mode in [source docs](https://firefox-source-docs.mozilla.org/accessible/ColorsAndHighContrastMode.html#operating-system-high-contrast-mode-os-hcm))

### STR:
1. Open Firefox on the New Tab page
2. Navigate to the "Personalize New Tab" (gear icon) button and activate it
3. On the "Personalize New Tab" dialog, locate and navigate to either of wallpaper group options, i.e. `Photographs`, and observe the focus state of the control (compared to other options' default view)
4. Select a wallpaper group and observe the selected/checked state of the control (compared to other options' default view)
5. Hover over a wallpaper group and observe the hovered state of the control (compared to other options' default view, both for the selected and not selected options)

### Expected:
1. Wallpaper options (both the parent/group and the inner options) are visually appearing as active elements with `ButtonText` and `ButtonFace` color combination and border, and, when focused with keyboard, it have a `CanvasText`-colored outline that clearly indicates that this element is, in fact, has keyboard focus. Hover and selected styles are also provided and are clear.

### Actual:
1. Wallpaper options (both the parent/group and the inner options) do not provide expected semantic styling for a control (a button, a radio button, or similar), specifically:
    1. the borders are `CanvasText` implying that these are static (not functional) elements, 
    1. hover styling adds a shadow effect (not expected on HCM), 
    1. no focus indication,
    1. no selectedness indication

### Remediation:
We need to ensure the focus outline is using `CanvasText` color and is allowed on `forced-colors` media, as well as that the appropriate color pairs are used for `forced-colors` [media query (HCM on Win)](https://firefox-source-docs.mozilla.org/accessible/HCMMediaQueries.html): `ButtonFace` with `ButtonText` for the border/label text and for the control background. The hovered state is expected to use `SelectedItem` and `SelectedItemText` color combination in place of the Button colors of the default state. The selected state adds a thicker border.

Adding a [Figma reference for color combinations for different Win10 and Win11 themes (SSO required)](https://www.figma.com/design/VHRA9hZ54oJqKKJwPd6FWa/High-Contrast-Mode?node-id=438-580), as well as the [radio buttons on HCM (SSO required)](https://www.figma.com/design/VHRA9hZ54oJqKKJwPd6FWa/High-Contrast-Mode?node-id=51-1303). With any questions or for more ideas, reach out to the Accessibility team in `#accessibility` in Matrix/Slack - we'd be happy to troubleshoot together.

### Note:
This applies to both the outer, group options, and the inner, individual wallpaper group options.