av9ash/GitBugs huggingface dataset:
Bug: [Experiment] Clicking the `OK` option on the Pin notification when it is displayed on the Windows lock screen does not pin Firefox
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2023-11-21 14:58:42+00:00
Resolved: 2023-11-22 19:59:55+00:00

**[Affected versions]:**
- Firefox Release 120.0 - Build ID: 20231116134553
- Firefox Beta 121.0b1 - Build ID: 20231120154937

**[Affected Platforms]:**
- Windows 11 Build 22631 (23H2)
- Windows 11 Build 22621 (22H2)

**[Prerequisites]:**
- Have the `nimbus.debug` pref set to true on a new clean profile.
- Have the `messaging-system.rsexperimentloader.collection_id` pref set to `nimbus-preview` on the same profile used above.
- Firefox is not default the default browser and it is not pinned to the taskbar.
- Have the `Hide content when notification are on lock screen` setting toggled.

**[Steps to reproduce]:**
1. Open the browser with the profile from prerequisites.
2. Copy and paste the following link in a new tab: `about:studies?optin_slug=windows-11-pinning-api-experiment&optin_branch=control&optin_collection=nimbus-preview`.
3. Navigate to the `about:welcome` page.
4. Click the `Save and continue` button.
5. Lock the screen then unlock it.
6. Toggle the `Hide content when notification are on lock screen` off.
7. Lock the screen and click the `OK` button from the notification.
8. Unlock the screen and right click the Firefox app in the taskbar.
9. Observe the app's pin status.

**[Expected result]:**
- Firefox is pinned.

**[Actual result]:**
- Firefox is not pinned and the notification is displayed again.

**[Notes]:**
- The issue is also reproducible when enrollment in the experiment is done naturally.
- The issue is reproducible with both branches.
- The issue is not reproducible is `Hide content when notification are on lock screen` off from the start.
- I could not reproduce the issue on the Nightly channel, because the notification is not triggered at all there. I'm assuming this has something to do with the channel and not the build.
- Attached is a screen recording of the issue: [link](https://drive.google.com/file/d/1qR7PhjKhm8t1XwXq2tPbkWc1zjiJz7TU/view?usp=drive_link)
Bug: V120: Address bar highlight changed with the same firefox theme
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-11-21 18:30:01+00:00
Resolved: 2023-12-04 15:00:54+00:00

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

Steps to reproduce:

Updated Firefox to V120


Actual results:

The ADDRESS URL BAR AT THE TOP  and it's SEARCH BAR changed from Sonic Blue to a bright sky blue when highlighting the text with the mouse/keyboard while using the same Theme i've used for years (This one https://addons.mozilla.org/es/firefox/addon/blue-mozilla-firefox/?utm_source=addons.mozilla.org&utm_medium=referral&utm_content=search )




Expected results:

The highlighted address URL bar and search words should've remained as to what the previous theme was like
Bug: Some tests are failing intermittently in pdf.js repo
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-11-21 19:54:33+00:00
Resolved: 2023-11-23 18:35:03+00:00

STR:
 - setup a local dev env for pdf.js: https://github.com/mozilla/pdf.js/#getting-the-code
 - run `gulp unittest`

Few tests (almost always the same) are more or less failing from a run to an other.
In using mozregression, I managed to get this push log:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=211dc86c8f534a950af69434fa996976b566a6a0&tochange=ff2400205932f8f2ee88d4b4f2680628e060434f

My feeling is that the worker cannot be gc-ed during a test.
For example this test is frequently failing:
https://github.com/mozilla/pdf.js/blob/83f00292129674c3b1c92c8629a8b50d3c5a6edd/test/unit/api_spec.js#L3806-L3874
The task is created at the beginning of the test and destroyed at the end.
The worker is created here:
https://github.com/mozilla/pdf.js/blob/83f00292129674c3b1c92c8629a8b50d3c5a6edd/src/display/api.js#L2122C27-L2122C27
then added in the `PDFWorker` object:
https://github.com/mozilla/pdf.js/blob/83f00292129674c3b1c92c8629a8b50d3c5a6edd/src/display/api.js#L2154-L2155
and the `PDFWorker` is added to the task:
https://github.com/mozilla/pdf.js/blob/83f00292129674c3b1c92c8629a8b50d3c5a6edd/src/display/api.js#L360C6-L360C6

:edenchuang, could you have a look please ?
Bug: Tab X close button moves to wrong position
Status: NEW
Priority: --
Created: 2023-11-21 20:36:19+00:00
Resolved: 2023-11-24 09:14:07+00:00

Steps to reproduce:

- set about:config option browser.tabs.tabMinWidth to 32
- open many tabs, so that just 1 character is visible for each tab
- move cursor to X button for active tab


Actual results:

X close button is moved a bit right, off the previous position and a bit off the tab area, so that X button is "jumping" between 2 positions, when moving a cursor.


Expected results:

X close button should stay at the same place.

It works good in Chrome and Edge, even if the tab width is the same, or even thinner.

Firefox 120.0 (64-bit), Windows 10 22H2 64-bit.

Tested also with the latest nightly, default settings, same result: 122.0a1 (2023-11-21) (64-bit)
Bug: The Address Bar suggestions' 3-dot-menu-button has a hover-styling that  feels more "severe" than Firefox's other similar buttons/menus. (Its foreground/background fully flip between light/dark when hovered)
Status: RESOLVED
Priority: P5
Resolution: WONTFIX
Created: 2023-11-21 22:15:06+00:00
Resolved: 2023-12-13 18:29:07+00:00

STR:
1. Start Firefox with a fresh profile.
2. Type `test search` into the URL bar and hit enter, to do a Google Search.
3. Open a new tab and type `test` into the address bar.
4. Hover the suggestion for your previous `test search` query (shown with a little clock icon next to it)
5. Hover the 3-dot-menu-button for that address-bar suggestion (which appears at the right side of that entry when you're hovering the entry), and notice how the button changes.

ACTUAL RESULTS:
- The 3-dot-menu button initially renders with black dots over a light gray background.
- When hovered, it changes to white (or lightgray) dots over a black (or dark gray) background.
- Essentially, it feels like the foreground/background colors get swapped when you hover it, roughly.

EXPECTED RESULTS: For consistency with the rest of our UI...
- The dots probably shouldn't change color when hovered.
- The background should only get a little darker, not as severe of a light-to-dark change that it undergoes right now.

Other bits of our UI show "expected results" -- e.g. the buttons at the bottom of the address bar, the hamburger menu, the 3-dot menus for each theme on `about:addons` and for each open tab in Firefox view, and the 3-dot toolbar menus in DevTools.

I recognize that this menu is slightly different than those ones since it's in an area that's already darkened due to the row being hovered, but it feels like we still could make the hover styling a bit closer to the hover styling for our other 3-dot-menu buttons (and less severe than the full light-to-dark flip that it has now).

I'm using Firefox Nightly 122.0a1 (2023-11-21) on Ubuntu 22.04
Bug: v119+ marionette raises sync failure
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-11-22 04:25:36+00:00
Resolved: 2023-12-06 15:09:43+00:00

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

Steps to reproduce:

I am using V112 and am able to log into my Mozilla account and sync normally.
When I upgraded to v121, I noticed that the sync was failing, although it was still possible to log in to the Mozilla account normally (it just didn't sync).


Actual results:

I tested versions after 112 one by one and found that the problem started with v119 and the reason that triggered it was the "-marionette" in the startup parameter, once this parameter was removed, the Mozilla account synchronized normally.
I checked the update log for v119 and didn't find anything about it.


Expected results:


Synchronizing normally in a marionette environment.
Bug: Opening the customize mode breaks the bookmarks/history sidebar bits (tree view gets confused)
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-11-22 07:53:07+00:00
Resolved: 2023-11-28 19:45:18+00:00

STR:

1. Open the bookmarks or history sidebar
2. Open the customize mode
3. Close the customize mode or switch the tab
4. Try to expand a row in the sidebar

Actual:

Nothing happens until you close and reopen the sidebar.

Expected:

Sidebar still works.
Bug: Webcompat report menu textbox missing text wrap
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-11-22 10:13:34+00:00
Resolved: 2023-12-05 15:07:52+00:00

**Found in**
* Beta v121.0b1

**Affected versions**
* Nightly v121.0a1
* Beta v121.0b1

**Tested platforms**
* Affected platforms:  Windows 10, MacOS 12, Ubuntu 22
* Unaffected platforms: -

**Preconditions**
* Make sure new webcopmpat feature is enabled:
ui.new-webcompat-reporter.enabled = true

**Steps to reproduce**
1. Load any webpage
2. Go to Hamburger Menu / Report broken site
3. Resize the "Describe the problem" textbox corner out of view
4. Try to resize the "Describe the problem" textbox again

**Expected result**
* The textbox can be resized

**Actual result**
* The textbox can't be resized because the resize corner is out of view and the menu is not scrollable

**Regression range**
* not a regression, but an implementation flaw.
Bug: Library window colors are mix of light and dark when opened from a private window with System theme
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-11-22 10:25:53+00:00
Resolved: 2024-01-16 12:31:01+00:00

STR:
1. Using the default "System theme - auto" with light system theme on Ubuntu 23.10.
2. Open a private window (Ctrl+Shift+P).
3. Open the Library (Ctrl+Shift+O) from the private window.

Expected:
Library uses light theme like the system.

Actual:
The Library toolbar and column headers are light but the rest is dark. Text in the toolbar has poor contrast.

Does not happen with `browser.theme.dark-private-windows = false`.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=cc927f0fc3f967e8adee36823ac2753fb93440f7&tochange=276cf96e94e0eb8e028dadb08f1d2ba1b08e2b18

Regressed by Bug 1846500.
Bug: --lwt-selected-tab-background-color is no longer available for userChrome.css in FF121
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2023-11-22 12:09:26+00:00
Resolved: 2023-11-22 17:32:21+00:00

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

Steps to reproduce:

* Had a userChrome.css in place that made use of --lwt-selected-tab-background-color
* Updated to FF121



Actual results:

* Saw elements that should have been colored with --lwt-selected-tab-background-color appear as black


Expected results:

* Elements should have retained their color 

After a bit of digging in the browser toolbox to see where the theme colors were exposed, the problem was fixed by changing "--lwt-selected-tab-background-color" to "--tab-selected-bgcolor" in the CSS.

This seems to have been an intended consequence of https://bugzilla.mozilla.org/show_bug.cgi?id=1859977. The code change in userChrome.css is trivial, but some time was expended in figuring out what was going on.

Should I have already known that "--lwt-selected-tab-background-color" was deprecated, and expected it to disappear?
Bug: The “Allow” and “Not now” buttons from the Top Opt-In section are not focused when using the “Up” and “Down” arrow keys for keyboard navigation
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2023-11-22 12:43:12+00:00
Resolved: 2023-11-22 16:57:18+00:00

**[Affected versions]:**
- Firefox Beta 121.0b1 - Build ID: 20231120154937
- Firefox Nightly 122.0a1 - Build ID: 20231121183118

**[Affected Platforms]:**
- Windows 10 x64
- Ubuntu 22.04 x64
- macOS 13.6

**[Prerequisites]:**
- Have a Firefox 121 or 122 en* build installed.
- Have the following prefs in the "about:config" page:
  - `browser.search.region` set to `US`;
  - `browser.urlbar.quicksuggest.contextualOptIn` set to `true`;
  - `browser.urlbar.quicksuggest.contextualOptIn.topPosition` set to `true`.

**[Steps to reproduce]:**
1. Open the browser with the profile from the prerequisites.
2. Click inside the Address Bar.
3. Press the “Down” arrow key 3 times.
4. Observe the behavior.

**[Expected result]:**
- The focus is moved from the “Learn more” link to the “Allow” button and ultimately to the “Not now” button.

**[Actual result]:**
- The focus is moved from the “Learn more” link to the first 2 results under the Opt-In section.

**[Notes]:**
- This issue is reproducible only when the Opt-In section is on Top.
- Attached is a [screen recording](https://drive.google.com/file/d/1-x_n9tKpewfTY7kbr-WkM3w_NRjmGEP-/view?usp=sharing) of the issue.
Bug: Sync attempts result in Connection Refused error
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2023-11-22 13:17:53+00:00
Resolved: 2024-07-01 12:23:28+00:00

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

Steps to reproduce:

Install the latest Firefox
Sign into a Mozilla Account
Attempt to sync settings etc.
Sync quietly fails

This error has occurred on both my home internet and my phone hotspot, in researching this issue I saw that there has been a history of some countries blocking AWS access but I don't think that's the issue since I am in Australia. 


Actual results:

The attached error was produced but Firefox doesn't show any signs of error in the UI


Expected results:

Settings, Bookmarks etc should be synced between the multiple devices signed into this Mozilla account
Bug: Dead keys in URLBar close the suggestion dropdown
Status: NEW
Priority: P5
Created: 2023-11-22 14:05:50+00:00
Resolved: 2023-11-27 16:38:29+00:00

I'm using the US Intl w/ dead keys keyboard layout. This uses the combination of `" + aou` for german umlauts, i.e. " is a dead key.  

When typing in the URLBar, the suggestion dropdown opens. As soon as I hit the ", the dropdown vanishes. When I continue typing, the drop down reappears. Best described in the attached video.
This behaviour is observed on MacOS Sonoma, both on current Release and current Nightly.
Bug: The title and the text description from the "Opt-In" section cannot be accessed by a screen reader software on macOS and Linux
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-11-22 14:30:28+00:00
Resolved: 2023-11-29 20:14:09+00:00

**[Affected versions]:**
- Firefox Beta 121.0b1 - Build ID: 20231120154937
- Firefox Nightly 122.0a1 - Build ID: 20231122095244

**[Affected Platforms]:**
- macOS 13.1
- Ubuntu 22.04 x64

**[Prerequisites]:**
- Have a Screen Reader software installed and enabled (I have used VoiceOver on macOS and Orca on Ubuntu 22.04).
- Have a Firefox profile with the following prefs in the "about:config" page:
	- `browser.urlbar.quicksuggest.contextualOptIn` set to `true`
	- `browser.search.region` set to `US`

**[Steps to reproduce]:**
1. Open the browser using the profile from the prerequisites.
2. Open a New Tab and click the "Address Bar".
3. Navigate through the "Address Bar" dropdown and observe the behavior.

**[Expected result]:**
- All the elements from the "Opt-In" section are successfully recognized by the screen reader software.

**[Actual result]:**
- Only the buttons and the "Learn more" hyperlink from the  "Opt-In" section are recognized by the screen reader software.

**[Notes]:**
- This issue is reproducible regardless if the "Opt-In" section is displayed at the top or at the bottom of the "Address Bar" doorhanger.
- This issue is not reproducible on Windows 10 x64 with the built-in screen reader (Narrator). All the elements are correctly recognized by the screen reader if the "Opt-In" section is displayed at the top of the “Address Bar” doorhanger. However, the "Opt-In" section cannot be accessed through the screen reader software if the section is displayed in the bottom part of the doorhanger.
Bug: The Opt-In section from the bottom is not dismissed after interacting with any of its buttons if the section is displayed for the first time (TypeError: queryContext is undefined)
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-11-22 15:17:16+00:00
Resolved: 2023-12-04 13:26:39+00:00

**[Affected versions]:**
- Firefox Beta 121.0b1 - Build ID: 20231120154937
- Firefox Nightly 122.0a1 - Build ID: 20231121183118

**[Affected Platforms]:**
- Windows 10 x64
- Ubuntu 22.04 x64
- macOS 13.6

**[Prerequisites]:**
- Have a Firefox 121 or 122 en* build installed.
- Have the following prefs in the "about:config" page:
- browser.search.region set to US;

**[Steps to reproduce]:**
1. Open the browser with the profile from the prerequisites.
2. Navigate to about:config page.
3. Set the "browser.urlbar.quicksuggest.contextualOptIn" pref to true and "browser.urlbar.quicksuggest.contextualOptIn.topPosition" pref to false.
4. Restart the browser. 
5. Click on the address bar.
6. Click on the "Allow suggestions" or "Not Now" button.
7. Observe the behavior.

**[Expected result]:**
- The Opt-In section is dismissed no errors are displayed in the browser console.

**[Actual result]:**
- The Opt-In section is NOT dismissed and an error is displayed in the browser console.

**[Notes]:**
- The Opt-In section disappears if the zero-prefix Address Bar is dismissed and re-displayed. Also, the buttons seem to work as expected even though the message remains displayed.
- The issue is only reproducible for the first impression of the Opt-In section.
- This issue is reproducible only when the Opt-In section is displayed in the bottom part. Is not reproducible with the Opt-In section when is displayed at the top.
- The following error is displayed in the browser console: "TypeError: queryContext is undefined      UrlbarProviderQuickSuggestContextualOptIn.sys.mjs:94:7"
- Attached is a screen recording of the issue.
Bug: Clean up "create docshell" property reads of gBrowser.docShell/browser.docShell
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-11-22 15:34:23+00:00
Resolved: 2023-11-24 04:29:37+00:00

https://searchfox.org/mozilla-central/rev/381c3f18a1896792e23a9503c1904aedac19aa06/browser/base/content/browser.js#1760-1761 and https://searchfox.org/mozilla-central/rev/381c3f18a1896792e23a9503c1904aedac19aa06/browser/base/content/tabbrowser.js#5146-5147 look superfluous. There may be more.
Bug: browser.ui.interaction.app_menu scalars do not increase when using the webcompat opened from Menu Bar or from Protections Panel
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2023-11-22 15:46:56+00:00
Resolved: 2023-12-15 15:41:48+00:00

**Found in**
* Beta v121.0b1

**Affected versions**
* Nightly v122.0a1
* Beta v121.0b1

**Tested platforms**
* Affected platforms: Windows 10, Ubuntu 22, MAcOS
* Unaffected platforms: -

**Steps to reproduce**
1. Flip ui.new-webcompat-reporter.enabled = TRUE
2. Load any webpage.
3. Open the webcompat reporter tool from the Menu Bar or from the Protections Panel
4. Go to about:telemetry and search for browser.ui.interaction.app_menu
**Expected result**
* appMenu-report-broken-site-button scalar should be increased by 1
**Actual result**
* appMenu-report-broken-site-button scalar does not count reporter tool interactions.
5. Open the webcompat reporter tool from the Menu Bar or from the Protections Panel, then click the Close button.
**Expected result**
* report-broken-site-popup-cancel-button scalar should be increased by 1
**Actual result**
* report-broken-site-popup-cancel-button scalar does not count the reporter tool being canceled.
6. Open the webcompat reporter tool from the Menu Bar or from the Protections Panel, then click the Send button.
**Expected result**
* report-broken-site-popup-send-button scalar should be increased by 1
**Actual result**
* report-broken-site-popup-send-button scalar does not count the report being sent.

**Regression range**
* Not a regression but a flaw of implementation.

**Additional notes**
* Reference in [QA Questions doc](https://docs.google.com/document/d/12wbZ0mPVl9xq28jIpdg3_Z8expNNwtz3Y9ibWiYXDwM/edit), Question no. 3.
Bug: Firefox external protocol handler prompt is vulnerable to clickjacking
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2023-11-22 16:17:13+00:00
Resolved: 2024-09-16 07:27:06+00:00

Opening a popup and initiating protocol URI on a hidden window; an attacker can lure the vicitim to clickjack the protocol handler prompt to allow the protocol unknowingly.

Steps to reproduce:
1. Download index.html and popup.html to a folder.
2. Open the index.html and start testing.
Bug: The webcompat reporter's confirmation screen is not readable in some combinations of High Contrast and Browser Themes on Windows
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-11-22 18:07:36+00:00
Resolved: 2023-12-07 12:07:57+00:00

**Found in**
* Beta v121.0b1

**Affected versions**
* Nightly v121.0a1
* Beta v121.0b1

**Tested platforms**
* Affected platforms: Windows 10
* Unaffected platforms: MacOS, Ubuntu

**Steps to reproduce**
1. Make sure new webcopmpat feature is enabled:
ui.new-webcompat-reporter.enabled  = true
2. Enable High Contrast White in Windows
3. Enable the Dark Theme in Firefox
2. Load any webpage
3. Go to Hamburger Menu / Report broken site
4. Sent a report and observe the confirmation screen.

**Expected result**
* The confirmation screen is properly displayed.

**Actual result**
* The text color contrast is incorrect and unreadable.

**Regression range**
* not a regression, but an implementation flaw.

**Additional information**
* The combinations of faulty behaviors:
1. HC-White + AlpenglowTheme
2. HC-White + Dark Theme
3. HC-Black + Light Theme
Bug: The "Send more info" link from the new webcompat reporter tool is not accessible by keyboard navigation
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-11-22 20:00:48+00:00
Resolved: 2023-12-04 13:52:06+00:00

**Found in**
* Beta v121.0b1

**Affected versions**
* Nightly v122.0a1
* Beta v121.0b2

**Tested platforms**
* Affected platforms: Windows 10, MacOS, Ubuntu 22
* Unaffected platforms: ?

**Steps to reproduce**
1. Flip:
ui.new-webcompat-reporter.enabled = TRUE
ui.new-webcompat-reporter.send-more-info-link = true
2. Load any webpage.
3. Open the webcompat reporter tool
4. Use keyboard navigation to reach and access the "Send more info" link

**Expected result**
* The link is reachable and accessible by Enter/Space key.

**Actual result**
* The link is reachable, but NOT accessible by Enter/Space key.

**Regression range**
* Not a regression but a flaw of implementation.

**Additional notes**
* This issue occurs without the use of a screen reader and also reproduces when using the JAWS screen reader, but it does not occur when running the NVDA screen reader.
Bug: When NVDA reads the new webcompat reporter dialog, the "Send more info" link is read twice, not presented as a link and somewhat confusing
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-11-22 20:22:58+00:00
Resolved: 2024-01-04 18:15:56+00:00

**Found in**
* Beta v121.0b2

**Affected versions**
* Nightly v121.0a1
* Beta v121.0b2

**Tested platforms**
* Affected platforms: Windows 10 + NVDA
* Unaffected platforms: ?

**Steps to reproduce**
1. Launch NVDA, then Firefox
2. Make sure new webcopmpat feature and the "Send more info link are enabled:
ui.new-webcompat-reporter.enabled  = true
ui.new-webcompat-reporter.send-more-info-link = true
3. Load any webpage
4. Go to Hamburger Menu / Report broken site
4. Observe how NVDA reads the new webcompat reporter tool.

**Expected result**
* The "Show more info" link is read once and it is presented as a link.

**Actual result**
* The "Show more info" link is TWICE once and it is NOT presented as a link and somewhat confusing as it is being read before reading the URL input box.

**Regression range**
* not a regression, but an implementation flaw.

**Additional information**
* The "Send more info" is presented as a link when selected specifically along with NVDA.