av9ash/GitBugs huggingface dataset:
Bug: The “X” button from the Sidebar callout is barely noticeable when using the dark theme
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-11-21 14:09:05+00:00
Resolved: 2024-11-22 12:17:54+00:00

[Affected versions]:
- Firefox Release Candidate 133.0 BUILD ID: 20241118181856

[Affected Platforms]:
- Windows 10.
- Ubuntu 22.04.
- macOS 14.7.

[Prerequisites]:
- User is enrolled in the “[Expand sidebar callout (new profiles)](https://experimenter.services.mozilla.com/nimbus/sidebar-button-feature-callout/summary)” rollout on a new profile.
- The “sidebar.verticalTabs” parameter from the “about:config” page is set to true.
- The default browser Dark theme is enabled from “about:addons>Themes”.

[Steps to reproduce]:
1. Open the browser with the profile from the prerequisites.
2. Open a new tab and access any webpage.
3. Observe the callout UI elements.

[Expected result]:
- All UI elements of the callout are displayed properly and fully visible when using a dark theme.

[Actual result]:
- The “X” button from the top right corner of the callout is barely noticeable.

[Additional Notes]:
- This issue is also reproducible with the “[Expand sidebar callout (existing profiles)](https://experimenter.services.mozilla.com/nimbus/sidebar-button-feature-callout-vertical-tabs-users-existing-profiles/summary)” rollout.
- This issue is not reproducible with the default browser Light Theme.
Bug: Wallpaper options missing their localized string when en-GB _seemed to be_ set as browser locale
Status: NEW
Priority: P3
Created: 2024-11-21 14:17:48+00:00
Resolved: 2025-01-17 16:19:37+00:00

(After writing this up, I'm suspecting it's not actualy a New Tab issue, but something else...)

I just switched to a new laptop and migrated my data over using Apple's Migration Assistant, including my applications and FF profiles.

I went to the wallpaper switcher (to show someone the cool new wallpapers) and noticed that it was showing the Fluent string placeholders.

[]()

In settings, I saw that en-GB was allegedly set as my browser language, so I thought maybe there was no en-GB string (unlikely, but was curious). I tried to set en-US as an additional language and saved. I then saw _en-GB_ strings correctly in the wallpaper picker. Going back to the languages picker afterwards, I saw that en-US wasn't actually saved in the list of Browser languages because I'd failed to hit 'Add' and just hit 'OK'

I'm wondering if when I moved over to the new machine, en-GB wasn't fully set as my browser language and hitting OK in the Languages dialog _did_ then set it properly...

Sorry to bring a mini mystery!
Bug: The Sidebar Callout overlaps the user’s tabs and doesn’t match the layout from the Callout tutorial
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-11-21 14:55:14+00:00
Resolved: 2024-11-22 12:30:32+00:00

[Notes]:
- This issue is partially reproducible on macOS: due to the position of the OS system buttons (close, minimize) all toolbar buttons are shifted to the right and the Callout no longer overlaps the user’s tabs. However, the order of the buttons being inconsistent with the Callout tutorial is still an issue.
- Due to this issue, the arrow from the Callout pointing toward the Sidebar button is missing on Windows 10 only. If the Sidebar button is manually moved to the right to match the Callout tutorial, it resolves this issue.

[Affected versions]:
- Firefox Release Candidate 133.0 BUILD ID: 20241118181856

[Affected Platforms]:
- Windows 10.
- Ubuntu 22.04.
- macOS 14.7.

[Prerequisites]:
- User is enrolled in the “[Expand sidebar callout (new profiles)](https://experimenter.services.mozilla.com/nimbus/sidebar-button-feature-callout/summary)” rollout on a new profile.
- The “sidebar.verticalTabs” parameter from the “about:config” page is set to true.

[Steps to reproduce]:
1. Open the browser with the profile from the prerequisites.
2. Open a new tab and access any webpage.
3. Observe the position of the Callout and the Sidebar button.

[Expected result]:
- The Sidebar Callout does not overlap the user’s tabs.
- The Sidebar button position is consistent with the Callout tutorial and displayed in the same position on the toolbar (to the right of the Refresh button).

[Actual result]:
- The Sidebar Callout overlaps the user’s tabs.
- The Sidebar button is displayed to the left of the Back button, on the first position from the toolbar.

[Additional Notes]:
- This issue is also reproducible with the “[Expand sidebar callout (existing profiles)](https://experimenter.services.mozilla.com/nimbus/sidebar-button-feature-callout-vertical-tabs-users-existing-profiles/summary)” rollout.
Bug: Address bar in titlebar no longer appears grayed for inactive windows with vertical tabs
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-11-21 15:10:54+00:00
Resolved: 2024-11-29 09:15:43+00:00

STR:
1. Start with `sidebar.verticalTabs = true`.
2. Create a new window.
3. a. Visit wikipedia.org by typing it into the address bar.
b. Visit wikipedia.org by clicking a link.
4. Switch focus to a different window.

Expected:
Everything in the titlebar appears grayed.

Actual:
Address bar appearance does not change.

First regression window (step 3a):
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d2e6af4871ea04a166c453153605f2229e73e95b&tochange=42d3134758c767b29889b2a3184fc869cc184d63

Regressed by Bug 1921811.

Second regression window (step 3b):
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=13537ae67079d33202b6570bb5a61d4ee652fecb&tochange=aa2b4302bdccdbfd659158479d68c4f377237e6c

Regressed by Bug 1927111.
Bug: tabs in tab bar shaking because of width changes
Status: NEW
Priority: --
Created: 2024-11-21 15:23:40+00:00
Resolved: 2024-12-09 12:20:30+00:00

Raul (CCed) shared how his Nightly (134.0a1) on Windows with ~20 tabs in the tab bar which causes it to be scrollable causes the tabs to shake because their width changes minimally in an endless loop: tabs to the left shake less because the width change accumulates over all tabs to the right. This endless reflow causes high CPU load.

He used Firefox 131.0.x before where he did not experience the issue. Disabling add-ons did not change the situation, an attempt to reproduce the issue in a private window with empty tabs did not reproduce it.
Bug: Unfocused address bar does not have contrast with Mozilla Colorway themes with vertical tabs
Status: NEW
Priority: P2
Created: 2024-11-21 15:34:10+00:00
Resolved: 2025-02-03 17:47:57+00:00

STR:
1. Start with `sidebar.verticalTabs = true`.
2. Install a Mozilla Colorway monochromatic theme like [Expressionist – Soft theme](https://addons.mozilla.org/en-US/firefox/addon/expressionist-soft/).
3. Unfocus the address bar.

Expected:
Address bar has a different background color to the titlebar when unfocused like with horizontal tabs.

Actual:
Address bar blends into titlebar without contrast.

Mozilla Colorway themes dominate the [top theme list](https://addons.mozilla.org/en-US/firefox/search/?sort=users&type=statictheme) so many users are affected.

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

Regressed by Bug 1899598.
Bug: Intermittent browser/components/search/test/browser/browser_searchbar_enter.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2024-11-21 16:56:32+00:00
Resolved: 2025-02-03 12:06:57+00:00

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

---
```
[task 2024-11-21T16:05:26.502Z] 16:05:26     INFO - TEST-PASS | browser/components/search/test/browser/browser_searchbar_enter.js | The search bar still has focus - 
[task 2024-11-21T16:05:26.503Z] 16:05:26     INFO - The focus is moved to the browser
[task 2024-11-21T16:05:26.503Z] 16:05:26     INFO - Buffered messages finished
[task 2024-11-21T16:05:26.503Z] 16:05:26     INFO - TEST-UNEXPECTED-FAIL | browser/components/search/test/browser/browser_searchbar_enter.js | Uncaught exception in test bound searchOnEnterSoon - AbortError: Actor 'SpecialPowers' destroyed before query 'Spawn' was resolved
[task 2024-11-21T16:05:26.504Z] 16:05:26     INFO - Leaving test bound searchOnEnterSoon
[task 2024-11-21T16:05:26.504Z] 16:05:26     INFO - Entering test bound typeCharWhileProcessingEnter
[task 2024-11-21T16:05:26.505Z] 16:05:26     INFO - Typing a char while processing enter key
[task 2024-11-21T16:05:26.646Z] 16:05:26     INFO - GECKO(5538) | 1732205126645	Marionette	TRACE	Received observer notification browser-delayed-startup-finished
[task 2024-11-21T16:05:26.682Z] 16:05:26     INFO - Keydown Enter
[task 2024-11-21T16:05:26.696Z] 16:05:26     INFO - Console message: [JavaScript Warning: "Key event not available on some keyboard layouts: key=“r” modifiers=“accel,alt” id=“key_toggleReaderMode”" {file: "chrome://mochikit/content/tests/SimpleTest/EventUtils.js" line: 1673}]
[task 2024-11-21T16:05:26.698Z] 16:05:26     INFO - Console message: [JavaScript Warning: "Key event not available on some keyboard layouts: key=“i” modifiers=“accel,alt,shift” id=“key_browserToolbox”" {file: "chrome://mochikit/content/tests/SimpleTest/EventUtils.js" line: 1673}]
[task 2024-11-21T16:05:26.701Z] 16:05:26     INFO - Keydown a char
[task 2024-11-21T16:05:26.704Z] 16:05:26     INFO - Keyup both
[task 2024-11-21T16:05:26.707Z] 16:05:26     INFO - TEST-PASS | browser/components/search/test/browser/browser_searchbar_enter.js | The value of searchbar is correct - "test" == "test" - 
```
Bug: "Closed # tabs" duplicate tabs notification is not announced to VoiceOver
Status: NEW
Priority: P3
Created: 2024-11-21 21:29:31+00:00
Resolved: 2024-12-02 12:30:10+00:00

STR: 
0. Enable VoiceOver
1. Open google.com in three separate tabs
2. Focus the tabstrip, then focus the active tab
3. Press VO+shift+M to launch the context menu
4. Select "Close duplicate tabs"

Expected: 
"Closed 2 tabs" is announced to VoiceOver

Actual:
No confirmation is given 

It is worth checking if this bug exists on windows or linux.
Bug: Translations Performance Impacted By Mutation Observer Changes
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-11-21 22:53:42+00:00
Resolved: 2024-12-11 09:52:02+00:00

### Description

Bug 1909632 ([push log](https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=8cdd04727200f4b9bee5a44801395a284903fd57&tochange=34b62cca961880f5f9338339b00feb858afd2e52)) introduced changes to the mutation observers for Translations, which fixed some long-standing bugs, but have introduced a new impact on performance for Translations. 

The following steps to reproduce feel like an edge case of triggering multiple translations in a row with auto-translate enabled, however I have noticed the same impact (though less reliably reproducible) when translating only a single page. 

I have particularly noticed this impact when testing out a `zhen` model and translating content on https://zh.wikipedia.org/wiki/Mozilla_Firefox.

---

### Steps to reproduce

> **Note**: 
> 
> See [attached video](https://bug1932780.bmoattachments.org/attachment.cgi?id=9439228) for example STR on Linux.
>
> The attached video shows behavior on Linux where hovering the mouse over a hyperlink triggers a translation for that node after the translation has stalled. I have only been able to reproduce this exact behavior on Linux. The slowdown is noticeable on macOS, however mousing over a hyperlink seems to have no effect. I have not tried yet on Windows. 

1) Open the browser to a translatable page, e.g. https://es.wikipedia.org/wiki/Mozilla_Firefox.
2) Enable auto-translate for the page language.
3) Click on new hyper links in rapid succession until the page translation is no longer quick.

**Expected Behavior**
The page translation is fast no matter how many links you click on.

**Actual Behavior**
The page translation stalls for much of the visible content after clicking on a few links in succession.
Bug: `nsWindowsShellService::CreateWindowsIcon` asserts in debug builds
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2024-11-22 01:17:16+00:00
Resolved: 2024-11-28 12:33:16+00:00

`CreateWindowsIcon` asserts in debug builds due to `SourceSurface::GetFrame` necessitating being called on the main thread.
Bug: Many keys on my keyboard are not showing up on websites
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2024-11-22 07:12:00+00:00
Resolved: 2024-12-10 14:14:18+00:00

Steps to reproduce:

I'm using a Raspberry Pi v5 8GB (arm), running Raspian, with the latest updates.




Actual results:

I tried to type in firefox on many different websites, and there's a large number of keys on my keyboard that simply don't register as being pressed.

Any other program on my machine works just fine, including Chromium and VSCode.

I tested this issue on a keyboard checking website (images included), and in the Raspberry Pi's keyboard config - it shows what keys are non-responsive in the browser, and that they work just fine elsewhere.


Expected results:

My text should've appeared on the screen.
Bug: Address bar input caret is not properly displayed
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-11-22 07:16:14+00:00
Resolved: 2024-11-22 07:35:33+00:00

**Found in**
* Fx 134.0a1

**Affected versions**
* Fx 134.0a1

**Affected platforms**
* Windows 10/11
* Ubuntu 24

**Steps to reproduce**
1. Launch Firefox.
2. Observe the address bar input caret.

**Expected result**
* Input caret is visible.

**Actual result**
* Only 1px of the caret is visible.

**Regression range**
* First bad: 11-22-2024
* Last good: 11-21-2024
* Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=57d71ba078d764e65f0b413761b1e73ca179c416&tochange=160977ed2e6cd8576c70840d388d1a6bcfc07262
* Potentially regressed by:  bug 1931466.

**Additional notes**
* Issue occurs regardless of Scotch Bonnet presence (on or off).
* In the attached screenshot it can be noticed that only 1px of the input caret is visible.
Bug: The Input text cursor is displayed above the placeholder text inside the Name Field in the Create a Tab Group panel
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-11-22 10:09:58+00:00
Resolved: 2024-11-22 11:38:44+00:00

**Found in**
* 134.0a1 (2024-11-22) 

**Affected versions**
* 134.0a1 (2024-11-22)


**Preconditions**
Set browser.tabs.groups.enabled	true

**Affected platforms**
* all

**Steps to reproduce**
1. Have a Few Tabs opened.
2. Add a Tab to a New Tab Group.

**Expected result**
* The input text cursor should be displayed at the beginning of the Placeholder Text.

**Actual result**
* The input text cursor is above the placeholder text in the Create Tab group panel.

**Regression range**
Not a Regression.
Bug: [Experiment] The microsurvey Addons CSAT is dismissed and the focus is moved to the address bar
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-11-22 11:53:54+00:00
Resolved: 2025-01-29 16:28:14+00:00

**[Affected versions]:**
- Firefox RC 133.0, BUILD ID: 20241121140525.
- Firefox Release 132.0.2 BUILD ID: 20241110231641

**[Affected Platforms]:**
- Windows 10 x64.
- macOS 14.3.

**[Prerequisites]:**
- Have the user.js file downloaded to your PC.
- Have a new Firefox profile with at least one add-on installed.
- Have Firefox set as the default browser or have the "Always check if Firefox is your default browser" option from the "about:preferences" page unchecked.
- Verify that the profile is not enrolled in the "nalexander PDF Annotations - Highlight - not default handler" experiment in order to be able to trigger our MicroSurvey in test.
- Have a profile that is older than 24h. 

**[Steps to reproduce]:**
1. Open the browser with the profile from the prerequisites.
2. Navigate to the profile folder and paste the user.js file from the prerequisites.
3. Restart the browser.
4. Open a new tab.

**[Expected result]:**
- The microsurvey remains displayed.

**[Actual result]:**
- The microsurvey is dismissed and the address bar is focused.

**[Notes]:**
- This issue is intermittent, I have managed to reproduce it approximately 3 out of 5 times.
- The issue is not reproducible on Ubuntu virtual machines.
- Another restart might be required after following the steps, in order to trigger the microsurvey.
Bug: The cursor position in he input field is incorrect.
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-11-22 12:19:53+00:00
Resolved: 2024-11-22 13:32:40+00:00

1) Go to "https://en.yamagiwa.co.jp/contact/".
2) Focus any input, for example "Your Name".
3) The cursor position is too upper.
4) The cursor position should be middle.

This issue happens in Nightly 134.0a1 (2024-11-21).
This issue didn't happen in Nightly 134.0a1 (2024-11-19).
Bug: [Experiment] The Firefox menu is dismissed if clicking inside the "DEVICE_MIGRATION_FXA_CTA_EXP1" message
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2024-11-22 12:57:39+00:00
Resolved: 2024-12-19 14:00:50+00:00

**[Affected versions]:**
- Firefox Release 133.0 (Build ID: 20241118181856)
- Firefox Nightly 134.0a1 (Build ID: 20241120171202)

**[Affected Platforms]:**
- Windows 10 x64
- macOS 15.0.1
- Ubuntu 24.04 x64

**[Prerequisites]:**
- Have following prefs set:
  - nimbus.debug = true
- Be enrolled in any of the treatment branches of the experiment. You can force enroll in the treatment-a branch by navigating to: about:studies?optin_slug=account-adoption-app-menu-experiment-firefox-release&optin_branch=treatment-a&optin_collection=nimbus-preview

**[Steps to reproduce]:**
1. Open the browser using the profile from the prerequisites.
2. Click the "Open application menu button" button in order to open the Hamburger menu.
3. Click inside the message displayed.

**[Expected result]:**
- Nothing happens.

**[Actual result]:**
- The Hamburger menu is dismissed.

**[Notes]:**
- The issue is also reproducible for the PXI menu. 
- Attached is a screen recording of the issue.
Bug: [134.0a1] Intermittent session loss after non-rendering "ghost" session
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2024-11-22 13:40:55+00:00
Resolved: 2025-01-28 13:48:00+00:00

Steps to reproduce:

This issue is unfortunately not _always_ reproducible nor is it obvious to me how to send any diagnostic information in the bugged state. I wish I had kept notes, but basically it happens less than a few times a month, but has now happened maybe twice in two weeks.

User agent:

```
Mozilla/5.0 (X11; Linux x86_64; rv:134.0) Gecko/20100101 Firefox/134.0
```

Build ID: 20241122092800

1. Configure Firefox to always restore your previous session on startup.

1. Quit the browser.

1. Start the browser and wait for the window to spawn.


Actual results:

* The window presented but the contents were not rendered.

* This is visually clear to me in my desktop environment (swaywm with a violently monochrome pink background, so an all-pink window means that the surface isn't rendering properly).

* Browsing _appears_ to work — blindly typing the sequence to open a new tab (with the URL bar focused), entering some random search term, and pressing "enter" changes the window title to reflect that the relevant query was passed to my search engine of choice. The window remains uniformly pink, though.

* Quitting the browser at this point and restarting it causes a brand-new session to open (i.e. Nightly appears to lose all my tabs).


Expected results:

The browser should have opened and worked as normal. Session should not be lost.
Bug: [Experiment] The default "Sync all your devices" option is displayed instead of the new "DEVICE_MIGRATION_FXA_CTA_EXP1" message if the Hamburger menu is quickly open after browser startup
Status: NEW
Priority: P3
Created: 2024-11-22 14:16:37+00:00
Resolved: 2024-12-19 13:56:43+00:00

**[Notes:]**
- The issue is also reproducible for the collapsed message which is displayed if the "DEVICE_MIGRATION_FXA_CTA_EXP1" one is dismissed. 
- The issue is also reproducible of the PXI menu. 

**[Affected versions]:**
- Firefox Release 133.0 (Build ID: 20241118181856)
- Firefox Nightly 134.0a1 (Build ID: 20241120171202)

**[Affected Platforms]:**
- Windows 10 x64
- macOS 15.0.1
- Ubuntu 24.04 x64

**[Prerequisites]:**
- Have the following prefs set:
  - nimbus.debug = true
- Be enrolled in any of the treatment b, c, or d branches of the experiment. You can force enroll in the treatment-b branch by navigating to: about:studies?optin_slug=account-adoption-app-menu-experiment-firefox-release&optin_branch=treatment-b&optin_collection=nimbus-preview

**[Steps to reproduce]:**
1. Open the browser using the profile from the prerequisites.
2. Quickly click the "Open application menu button" button in order to open the Hamburger menu.
3. Observe the options.

**[Expected result]:**
- The new "DEVICE_MIGRATION_FXA_CTA_EXP1" message is displayed.

**[Actual result]:**
- The default "Sync all your devices" option is displayed.

**[Additional Notes]:**
- Attached is a screen recording of the issue.
Bug: copying space characters from URL bar with URL in front of it causes characters to be added to the string when copied into RAM
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2024-11-22 15:04:27+00:00
Resolved: 2024-11-25 13:44:07+00:00

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

Steps to reproduce:

1. copy this string (example) into the URL bar and hit enter:
`https://bugzilla.mozilla.org/ Security-Sensitive Firefox Bug userlist`
2. "raptor not found" page should appear, now copy the string that is now present in the URL bar
3. paste that string in the URL bar again
4. paste that string also in the search field in your toolbar (make sure you also have the search field in the toolbar)


Actual results:

string is falsified in both URL bar and searchfield, displays `https://bugzilla.mozilla.org/%20Security-Sensitive%20Firefox%20Bug%20userlist` instead of `https://bugzilla.mozilla.org/ Security-Sensitive Firefox Bug userlist`


Expected results:

At least in the search field, the string **definitely** should **not** be containing any characters that are not visible in the string in the URL bar at the moment of copying that string.