av9ash/GitBugs huggingface dataset:
Bug: Border of Shortcuts select control on the about:newtab page's settings dialog has low color contrast
Status: NEW
Priority: --
Created: 2024-04-23 20:41:50+00:00
Resolved: 2024-09-16 15:21:10+00:00

The color contrast for the combobox with the row numbers for `Shortcuts` on the Settings dialog of the `about:newtab` page is not sufficient:
1. Light theme:
    1. Foreground: #BABBBC
    1. Background: #FFFFFF
    1. The contrast ratio is: 1.9:1 (min 3:1 is expected)
    1. [WCAG 2.2 1.4.11 Non-text Contrast (AA)](https://www.w3.org/WAI/WCAG22/Understanding/non-text-contrast.html) - Fail for UI components and graphical objects
1. Dark theme:
    1. Foreground: #605E65
    1. Background: #413F4B
    1. The contrast ratio is: 1.6:1 (min 3:1 is expected)
    1. [WCAG 2.2 1.4.11 Non-text Contrast (AA)](https://www.w3.org/WAI/WCAG22/Understanding/non-text-contrast.html) - Fail for UI components and graphical objects
Bug: The SelectTranslationsPanel settings menu is not accessible via keyboard
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2024-04-23 20:59:46+00:00
Resolved: 2024-05-15 10:06:41+00:00

### Description

Right now the SelectTranslationsPanel settings button is skipped over when navigation the keyboard with Tab.

We need to ensure it is accessible. 

---

### Steps to implement

* Give the settings button a tabindex value of `"0"`.

---

### Tests to implement

* Add tests to ensure tab index order is correct.
Bug: Update wallpaper onboarding thumbnail images
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2024-04-23 22:01:11+00:00
Resolved: 2024-04-25 17:14:57+00:00

In order to address a bug with auto light/dark theming on MacOS we are creating light/dark counterpoints for all wallpapers. The thumbnails for onboarding are in-tree so we need to update those with the new images.
Bug: XUL Elements are not focusable in SelectTranslationsPanel on macOS
Status: RESOLVED
Priority: P3
Resolution: WONTFIX
Created: 2024-04-24 04:22:19+00:00
Resolved: 2024-04-29 14:06:09+00:00

### Description

XUL elements within the SelectTranslationsPanel are unable to receive focus on macOS.

I used mozregression to trace the source of the issue back to this exact patch:
Bug 1878721 - [Phab-D205730](https://phabricator.services.mozilla.com/D205730)

I had initially been implementing the SelectTranslationsPanel with the `<panelmultiview>` as a naive way to follow some prior art, but I realized that I did not actually need the `<panelmultiview>` functionality so I removed it. 

This is when the keyboard navigation apparently broke and XUL elements could no longer receive focus in just a `<panel>` without the `<panelmultiview>`. 

--- 

### Troubleshooting So Far

* Everything works fine on Linux (I have not tested yet on Windows).

* XUL elements are still not focusable even when I add `tabindex="0"` to them explicitly. 

* When I try to focus them programmatically, the `document` does recognize them as the active element, but they are not visually outlined, nor do they respond to keyboard events.

* HTML elements _are_ correctly focusable in the panel. I even experimented with this by changing all of the XUL `<button>` elements to `<html:button>` elements. This regressed some of the styling/layout, but the elements were focusable again.
Bug: Firefox installer times out on official Win11 test VM, showing error dialog "Hmm. For some reason, we could not install Firefox Nightly. Choose OK to start over."
Status: VERIFIED
Priority: --
Resolution: DUPLICATE
Created: 2024-04-24 06:08:16+00:00
Resolved: 2024-04-25 18:21:59+00:00

STR:
1. Download a Windows 11 test virtual machine (for VirtualBox in my case) from https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/
2. Extract, import, and run the virtual machine.
3. Run the Firefox Nightly installer available from https://nightly.mozilla.org/ (downloaded via e.g. Edge)
4. Watch the progress bar.

ACTUAL RESULTS:
The progress bar quickly goes to ~2/3 done, and then **very slowly** animates towards completion from that point onwards, essentially stalling for several minutes. After minutes have passed, when the bar has very gradually animated to a point where it's nearly full, a dialog appears saying "Hmm. For some reason, we could not install Firefox Nightly. Choose OK to start over."

EXPECTED RESULTS:
No such error.

ADDITIONAL NOTES:
- Despite the error popup, it seems that Firefox Nightly was successfully installed - we got a desktop launcher (which works just fine), an entry shown in Add/Remove programs, etc.
- I've tried the STR as *literally* the first thing that I do after starting up the test VM, and I've also tried performing the STR in another freshly unpacked instance of the VM where I've first installed Windows Updates. The same issue happens either way.
- I tried installing Chrome, for comparison. They don't hit the same issue. [EDIT: Nor does Firefox release version, fortunately, per comment 3].
Bug: Upon opening a PDF document, the PDF opens but a print dialog also pops up along with a Save to PDF option. This has happened after I recently updated to the latest version of Firefox 125.0.2 (64-bit) - Mozilla Firefox for Linux Mint
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-04-24 08:38:32+00:00
Resolved: 2024-04-24 09:00:38+00:00

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

Steps to reproduce:

Opened a PDF file and it opens up in the Firefox browser.


Actual results:

The file opens but with a Print Dialog (Save to PDF) on top of it.


Expected results:

Only the PDF should be viewed and no print dialog should pop up.
Bug: The in-built pdf viewer lacks a highlight icon on the toolbar.
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-04-24 08:59:48+00:00
Resolved: 2024-04-24 10:35:45+00:00

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

Steps to reproduce:

Open a pdf with text. On top there are the annotation icons but not the highlight one. If, you select a text and right-click on it, you can highlight selection. When you do a "dropdown" options menu appears next to the text input icon. See screenshot.


Actual results:

It is not possible to select the highlight text annotation option directly. Workaround is through select text, right-click, highlight selection.


Expected results:

An icon in the toolbar next to the enter text annotation button.
Bug: getDisplayMedia succeeds on macOS without system permission if camera or mic capture is active
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-04-24 09:42:38+00:00
Resolved: 2024-04-25 09:14:42+00:00

Steps to reproduce:
0. In System Settings -> Privacy & Security -> Screen & System Audio Recording revoke the permission for the app you're testing in, if present.
1. In a tab open https://codepen.io/nagamanikanta001/pen/YzMBNbK?editors=1111
2. Click either button for mic or camera access and approve the doorhanger
3. In the same *or another* tab with the same page *or [something else](https://mozilla.github.io/webrtc-landing/gum_test.html)* click the button to capture the screen. Pick a window or screen in the doorhanger and approve.

Expected result:
`NotFoundError` because system permission has been revoked.

Actual result:
getDisplayMedia succeeds but the video either 1) for window capture doesn't yield any video frames, or 2) for screen capture yields some occasional frames of the desktop background, without windows showing.
Bug: Nightly build takes aprox 5 minutes to install from .exe being stuck at default browser agent, background task and when uninstalling
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-04-24 11:10:16+00:00
Resolved: 2024-04-25 18:21:48+00:00

**Found in**
* Nightly 127.0a1 - 20240422094829

**Affected versions**
* Nightly 127.0a1 - 20240422094829

**Tested platforms**
* Affected platforms: Windows 10 and Windows 11 (.exe)
* Unaffected platforms: mac, Ubuntu

**Steps to reproduce**
1. Download the nightly build from https://archive.mozilla.org/pub/firefox/nightly/2024/04/2024-04-22-21-46-52-mozilla-central/firefox-127.0a1.en-US.win64.installer.exe
2. Install the build

**Expected result**
* The build is installed in a few seconds

**Actual result**
* The build takes almost 5 minutes or more to install and it gets stuck at `default-browser-agent.exe register-task 6F193C...` and `--backgroundtask install`
* This is also the case when uninstalling, it also takes ~5 minutes to do so (from Control Panel or helper.exe)

**Regression range**
* First bad: 22.04.2024 - 20240422214652
* Last good: 22.04.2024 - 20240422094829
* Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d4a6129fdbbe32300d5069df6ce47dd92f665c96&tochange=ed724b89a2c25252a6eab99f0fa48f85f2523b66
* Potentially regressed by: Not sure what might have caused this

**Additional notes**
* I think this could be similar or the same as bug 1893109
* This was tested in VM, Sandbox and normal Windows install on PC.
* .msi, snap are also affected but msix not.
Bug: Using <div>s instead of <message-bar>s for shopping messages regressed icons
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-04-24 14:25:38+00:00
Resolved: 2024-04-25 09:48:06+00:00

The stale, analysis in progress, and re-analysis in progress shopping message bars previously displayed icons that were part of the `<message-bar>` markup. When switching these messages to `<div>`s I didn't see the icons (they weren't visible in Storybook...) so overlooked re-implementing them in the new markup - as a result the icons are no longer displayed.
Bug: Address bar behaves poorly when loading is slow opening a new window with homepage URL set
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-04-24 15:28:44+00:00
Resolved: 2024-04-29 15:30:30+00:00

When opening a new window, while having a homepage URL set, if the page starts loading after the users has clicked the address bar the cursor will end up at the start of the address bar and the user's typing will result in 'invalid' contents.

Steps to reproduce:

1. Set your Home page to a URL
2. Use a slow site or be on a slow network connection
3. Open a new window
4. Click the URL bar
5. Type something

Expected result:

You can keep typing while the home page loads.

Actual result:

Your cursor is placed before the home page URL and the home page URL will be appended to your typing.
Bug: Tile and `...` button do not differentiate the hover state on the about:newtab
Status: NEW
Priority: --
Created: 2024-04-24 16:40:31+00:00
Resolved: 2024-10-01 17:52:54+00:00

The hover indication is shared across the `...` buttons and their tiles on the `about:newtab` page.  It applies both to the tiles and story cards.

Being able to easily discern what exactly is hovered with a pointer is crucial for multiple groups of mouse users, especially those with limited vision or with a glare on their screens, with cognitive difficulties, ADHD, anxiety, as well as users with limited mobility who would risk activating wrong control otherwise or feel lost on the page. It's even more important when the controls are placed so closely to each other as the tile and its `...` button (thus, the severity is `access-s3`)

It is recommended that the hover, as any other state of active UI, would [not rely on a use of color alone](https://www.w3.org/WAI/WCAG22/Understanding/use-of-color.html) and to ensure the indication provides [at least 3:1 in color contrast](https://www.w3.org/WAI/WCAG22/Understanding/non-text-contrast.html) between both the page background and the non-hovered control appearance. I this case, when the tile is focused, it is expected that the focused state would be apparent both within the set of tiles and next to the `...` button, and vice versa.

Note: the bare minimum indication of hover to be provided is a change in pointer and/or addition of the tooltip. That's being said, this does not guarantee and does not provide a delightful experience, because users with low vision or neurodivergent users may have customized pointer and/or the tooltip may appear outside of the view of the magnification software. Also, tooltips have a slight delay that may make it harder for a  user with cognitive difficulties to connect the hover and tooltip actions together, or it may distract a user with ADHD. Thus, providing a clear hover indication is highly recommended.
Bug: Contextual Search only searches first letter
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2024-04-24 20:29:56+00:00
Resolved: 2024-04-27 19:56:06+00:00

Enabling secondaryActions and visiting wikipedia, if you enter "test" in the urlbar and select "Search with Wikipedia" then it will run the search for "t" only
Bug: Add two prefs for light/dark newtab wallpapers
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-04-24 20:34:27+00:00
Resolved: 2024-04-29 17:18:22+00:00

There is currently a bug on MacOS system "auto" theme where the theme changes from light/dark depending on the time of day. To account for this, we should have separate background prefs for light and dark themes that persist if a user alternates theme.
Bug: SelectTranslationsPanel footer buttons are in the wrong order on Windows
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2024-04-25 00:03:22+00:00
Resolved: 2024-06-03 13:35:02+00:00

### Description

In Bug 1893100 [D207602](https://phabricator.services.mozilla.com/D207602) I lowered the copy button into the footer in its own start-justified group. Likewise, I moved the other footer buttons into their own end-justified group.

This achieves the correct visual effect within the panel, but the Windows-specific button order is no longer correct (see screenshot).

We need to figure out what changes will allow the Windows-specific button-order logic to persist through this new structure of elements. 

---

### Before the regression

Prior to the regression the structure looked something like this:

```html
<html:moz-button-group>
  <button></button>
  <button></button>
  <button default="true"></button>
  ...
</html:moz-button-group>
```

---

### After the regression

After to the regression the structure looked something like this:

```html
<html:moz-button-group>
  <html:div>
    <button></button>
  </html:div>
  <html:div>
    <button></button>
    <button></button>
    <button default="true"></button>
  </html:div>
</html:moz-button-group>
```

---

Itiel, do you have any ideas on how to fix this?
Bug: If I have Firefox set to always use Private Browsing, I never get the private browsing disclaimer or reference link
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2024-04-25 08:01:56+00:00
Resolved: 2024-05-06 07:47:14+00:00

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

Steps to reproduce:

With Remember history set:

1. File > New Private window
2. Click the + sign in the private window for a new tab
3. Repeat steps 1 and 2 multiple times

With Never remember history -or- Custom + Always use private browsing set (restart to use):

1. File > New Private window
2. Click the + sign in the private window for a new tab
3. Repeat steps 1 and 2 multiple times


Actual results:

With Remember history set:

For all 3 steps, always get the message "Private window: Firefox clears your search and browsing history when you close all private windows. This doesn’t make you anonymous." as well as a link to more information.

No matter how many times you do steps 1-3 you always get the above result, and there is no way to never show again. So presumably someone at Mozilla considers this message super important.

This is as opposed to the message about private browsing on mobile, which shows up once and I can dismiss by clicking the x.

With Never remember history -or- Custom + Always use private browsing set (restart to use):

I never get the message, not even when I set the preference in settings.


Expected results:

With Remember history set:

Behaving as expected.

With Never remember history -or- Custom + Always use private browsing set (restart to use):

For all 3 steps, always get the message "Private window: Firefox clears your search and browsing history when you close all private windows. This doesn’t make you anonymous." as well as a link to more information.
Bug: Pin to taskbar notification appears twice.
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-04-25 11:17:56+00:00
Resolved: 2024-05-18 20:27:57+00:00

**Found in**
* version: 127.0a1

**Affected versions**
* version: 127.0a1

**Tested platforms**
* Affected platforms: Windows
* Unaffected platforms: Mac, Ubuntu

**Preconditions**
* Have Firefox installed

**Steps to reproduce**
1. Close Firefox and delete all profiles.
2. Do a windows restart/log off.
3. Log in to windows and start Firefox.
4. Open about:welcome page.
5. Check only  ‘pin to taskbar’ and press on save.
6. Once the notification is displayed press on the title bar (do not press Yes/No,thank)

**Expected result**
* The notification should disappear and Firefox should not be pinned to taskbar .

**Actual result**
* Notification is removed but a new one is displayed.

**Regression range**
* Not a regression recently added.

**Additional notes**
* This seems to reproduce with both .exe and .zip builds on Windows Beta(23H2 (22631.2861)/(22H2 - 22621.3527)) and Release (23h2 (22631.3447)).
* Does not reproduce with 125.0 build.
Bug: Taskbar pinning races shortcut creation propogating through Windows shell
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-04-25 13:35:21+00:00
Resolved: 2024-11-21 14:02:48+00:00

**Found in**
* Latest Nightly 127.0a1

**Affected versions**
* Latest Nightly 127.0a1

**Tested platforms**
* Affected platforms: Windows 11 Dev and Canary channels only - 24h2 (26080.1 and 26100.1)
* Unaffected platforms: MacOS and Ubuntu

**Preconditions**
* Have a clean Windows with no Firefox installed
* Clean the Windows is previous Firefoxes were installed by deleting the following:
```
Delete HKEY_CURRENT_USER\SOFTWARE\Mozilla
Delete HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla
Delete HKEY_LOCAL_MACHINE\SOFTWARE\mozilla.org
Delete HKEY_LOCAL_MACHINE\WOW6432Node\Mozilla
Delete any folder with Mozilla from C:\Program Data
Delete all folders with Mozilla from C:\user\AppData\Local | Roaming | LocalLow
```

**Steps to reproduce**
1. Install latest Nightly (.exe)
2. Visit about:welcome page
3. Leave only `Pin Nightly to taskbar` checked
4. Click on the `Save and continue` button

**Expected result**
* A system notification is displayed asking the user to pin Firefox to taskbar.

**Actual result**
* No notification is displayed
* The notification will appear if user restarts Nightly and does steps 2-4 again OR by staying in the same session and doing steps 2-4 again.

**Regression range**
* Not a regression since this is a new implementation.

**Additional notes**
* Gif showing the issue attached
Bug: [RTL] The buttons for the Screenshots selection are placed on the right side
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-04-25 13:43:57+00:00
Resolved: 2024-05-08 12:51:07+00:00

**Found in**
* Nightly 127.0a1

**Affected versions**
* Nightly 127.0a1

**Tested platforms**
* Affected platforms: Windows 10 x64, Ubuntu 22.04 and macOS 13

**Preconditions**
* install an RTL build - ar in my case.

**Steps to reproduce**
1. Enable Screenshots by pressing the Cmd+Shift+S keys.
2. Do a Screenshot selection by mouse drag.
3. Observe the buttons of the Screenshot selection.

**Expected result**
* The 'Download', 'Copy' and 'X' buttons should be located on the left side of the Screenshot selection.

**Actual result**
* The buttons are located on the right side of the Screenshot selection. Please see the screenshot for more details.

**Regression range**
* Not a regression, it's reproducible only when the component version of Screenshots is enabled.
Bug: Remove unneeded await on l10n.setAttributes in ContentAnalysis.sys.mjs
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-04-25 16:14:11+00:00
Resolved: 2024-04-26 04:21:12+00:00

Per :gijs this is probably OK because this only needs awaiting for an `import` statement on a module that has likely already been imported. But we should fix it.
Bug: Firefox hung on startup - nothing redrawn in its windows when SOCKS proxy is missing
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2024-04-25 16:41:03+00:00
Resolved: 2025-01-30 10:56:40+00:00

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

Steps to reproduce:

1. Run Firefox, and use a SOCKS proxy (on localhost).
2. Quit Firefox.
3. Make sure that the proxy no longer works (I rebooted the machine, so that the ssh providing the proxy was no longer running).
4. Run Firefox (I got connection errors due to the missing proxy).
5. Switch to "No proxy".
6. Quit Firefox.
7. Run Firefox.


Actual results:

After step 7, Firefox hung (AFAIK, I have never got this issue before). Several windows (from the previous session) and 2 notification boxes appeared, but with nothing drawn in them except tabs and toolbars. After that nothing got redrawn.


Expected results:

After restarting Firefox, the windows from the previous session opened and I also got a dialog box to enter my primary password. After entering my password, everything was OK.

Note: I tried to get a backtrace of the attached Firefox process. As gdb was slow, I thought I did something wrong, so that I did a Ctrl-C in gdb to restart it. But when quitting gdb, this made Firefox quit (or this was just a coincidence). So I do not have any debugging information.
Bug: Cannot drag tab to certain part of bookmarks toolbar to save it as bookmark because of tab preview
Status: RESOLVED
Priority: P1
Resolution: DUPLICATE
Created: 2024-04-25 19:39:03+00:00
Resolved: 2024-05-08 15:57:26+00:00

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

Steps to reproduce:

I cannot drag tab to certain part of bookmarks toolbar to save it as bookmark because of tab preview blocks the view.


Actual results:

I cannot drag tab to certain part of bookmarks toolbar to save it as bookmark because of tab preview blocks the view.


Expected results:

Tab preview should not block the view of bookmark toolbar so i can freely drag tab anywhere.
Bug: Every other new tab does not smoothly slide in
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2024-04-26 01:31:04+00:00
Resolved: 2024-07-04 18:41:02+00:00

Steps to reproduce:
1) Open a new tab
2) Open another new tab
3) Open another new tab
4) Open another new tab
5) Open another new tab
6) Open another new tab

Actual results:
Every other tab will not smoothly slide in

Expected results:
Every tab will smoothly slide in
Bug: CMYK PDF blending renders incorrectly
Status: NEW
Priority: P3
Created: 2024-04-26 05:33:18+00:00
Resolved: 2024-05-30 13:00:06+00:00

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

Steps to reproduce:

I've loaded a PDF file content into iFrame, for preview purpose, while generating the PDF "on the fly".


Actual results:

The PDF in Acrobat Reader or Adobe Illustrator renders without problem, however on Firefox, the blending that suppose to be done in CMYK (as stated in the file itself) are done RGB-based, like the CMYK settings within the file been ignored.


Expected results:

Blending color space specified in PDF v1.6 (the version of my PDF file) is CMYK, and so the processing should be as per the PDF specification for CMYK blending.
In the attached file, the blending been used is "Screen", under CMYK calculation, the Red circles behind the Green circles should become more yellowish, and behind the Blue circle should become white.