av9ash/GitBugs huggingface dataset:
Bug: When unloading all tabs, don't show Firefox View if it has been removed
Status: ASSIGNED
Priority: P3
Created: 2025-02-06 14:13:24+00:00
Resolved: 2025-02-28 14:05:17+00:00

This is tricky because there's nothing else to select in this case. I guess we can just select some other tab...

Note that we used to check for `FirefoxViewHandler.tab` in [this else case](https://searchfox.org/mozilla-central/rev/d1fbe983fb7720f0a4aca0e748817af11c1a374e/browser/components/tabbrowser/content/tabbrowser.js#4918-4922), which would fix this, but `FirefoxViewHandler.tab` can be undefined if the Firefox View button is present but it has never been loaded.
Bug: [IAB Medium rectangle] Variant A has hover state of cards and lack rounded corner at the bottom for default state
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2025-02-06 14:14:46+00:00
Resolved: 2025-02-22 09:18:54+00:00

How to reproduce it?
- Being in Variant A of Medium Rectangle IAB

Current behavior:
- When Medium rectangle is visible, not hover, the two bottom corners are not rounded as the top corners.
- When Medium rectangle has mouse hover, the state of hover takes the full length as it happens with content cards.

Expected behavior:
- Medium rectangle state=default has 4 corners rounded.
- Medium rectangle state=hover show the contextual menu and not the container of the card.
Bug: Icons (except site icons) and text are not displayed when sidebar.revamp and certain theme are enabled.
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2025-02-06 15:03:53+00:00
Resolved: 2025-02-14 09:44:32+00:00

STR:
1. Install theme e.g., https://addons.mozilla.org/en-US/firefox/addon/miincdesign_33/
2. Enable sidebar.revamp
3. Optionally  enable sidebar.verticalTabs

Actual results:
Icon(except site icon) and text are not displayed

Expected results:
should be displayed
Bug: Calculator: Multiple commas/periods should be treated as separators not as decimal points
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2025-02-06 15:42:08+00:00
Resolved: 2025-02-20 14:15:32+00:00

**STR**
- Type in "1,000,000 + 50" into urlbar

**Expected**
- Calculator result is "1,000,050"

**Actual**
- Calculator result is "51"

**Preconditions**
- browser.urlbar.suggest.calculator set to true
Bug: Swtiching tabs with command + 1 to 9 broken
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2025-02-06 15:57:38+00:00
Resolved: 2025-02-06 17:41:42+00:00

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

Steps to reproduce:

Update Firefox to 135. Have multiple tabs open. Try switching tabs with command + 1 to 9.

Issue did not exist in Firefox 134 or earlier. Issue also exists in Beta (136.0b2) and Nightly (137.0a1).

Other shortcuts like command + shift + [ still work.


Actual results:

Nothing.


Expected results:

Switch to the first to eighth or last tab, depending on the number.
Bug: Downloaded PDF unexpectedly deleted when Private browsing window is closed
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-02-06 15:59:49+00:00
Resolved: 2025-02-11 13:17:29+00:00

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

Steps to reproduce:

Comments:
This is a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=1738448 I don't have permission to comment on that closed bug. That bug seems to indicate it is only a problem for PDF files downloaded from PDF.js, but I can repeat it in other common circumstances where both an average user and HTTP headers expect a download rather than an opened file.

Steps to repeat:
1) Open a private browsing window and navigate to Gmail.
2) Open an email with a PDF attachment.
3) Click the button labeled "Download" 
4) The browser receives this HTTP response for the PDF:

  HTTP/2 200 
  content-type: application/pdf
  cache-control: private, max-age=20
  date: Thu, 06 Feb 2025 15:37:16 GMT
  x-xss-protection: 0
  access-control-allow-credentials: true
  access-control-expose-headers: Content-Disposition,Content-Length,X-Content-Type-Options
  content-disposition: attachment; filename="example.pdf"; filename*=UTF-8''example.pdf
  content-length: 95602
  content-security-policy: require-trusted-types-for 'script';report-uri https://mail.google.com/mail/cspreport
  x-content-type-options: nosniff
  server: GSE
  alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
  X-Firefox-Spdy: h2

5) Check that Firefox shows the download as complete.
6) Open Windows Explorer.
7) Copy the file to another folder
8) Close or leave open the PDF files that were opened as tabs in the private browsing window (Doesn't matter)
9) Confirm that the file still exists in my Downloads folder (it does)
10) Close the private browsing window


Actual results:

The copy of the file that I made in Windows Explorer still exists, but the original in my downloads folder was deleted when the private browsing window closed.


Expected results:

The copy of the file that I made in Windows Explorer still exists, and the original in my downloads folder still exists.

In particular, I note the "content-disposition: attachment" HTTP header, which I think means the browser should treat it as a download not a file to open.
Bug: Opening and closing a new tab causes the existing tab to be scrolled to top
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2025-02-06 17:40:31+00:00
Resolved: 2025-02-06 17:45:33+00:00

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

Steps to reproduce:

Webpage A was opened and scrolled approximately halfway down. I opened a new tab and then closed it using the keyboard shortcuts (Ctrl-T, Ctrl-W).


Actual results:

Webpage A ended up scrolled to the top of the page.


Expected results:

Webpage A should have remained at the scroll position before I opened a new tab. My system was not under memory pressure. This issue does not occur if I open and close a new tab using my mouse.
Bug: mozilla account "disconnected" after firefox is closed and relaunched
Status: UNCONFIRMED
Priority: --
Created: 2025-02-06 17:41:08+00:00
Resolved: 2025-03-03 15:47:15+00:00

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

Steps to reproduce:

Similar to what's listed here: https://bugzilla.mozilla.org/show_bug.cgi?id=1933038

Unlike that post, I do not have a primary password set up.

1 - closed/quit firefox
2 - start firefox

Do note I get the same behavior on both Firefox 134/135/128.7ESR on MacOS; 134 on Windows as well. I tried relaunching the browser using troubleshooting mode. Tried completely logging off and logging in again by removing the session on my mozilla account "Connected Services".


Actual results:

Warning sign on menu icon, "disconnected account" message shows up;
Requires login;
2FA only works after trying twice ("error, please close this tab and start again" the first time after 2FA code)


Expected results:

Firefox sync/mozilla account should stay connected and logged in
Bug: Prevent URL bar from showing through preonboarding modal
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2025-02-06 18:01:53+00:00
Resolved: 2025-02-12 10:31:38+00:00

[Tracking Requested - why for this release]: Supports experimentation in Fx136 (see [Jira](https://mozilla-hub.atlassian.net/browse/FIDE-2314))

Address issue where URL bar bleeds through preonboarding Spotlight modal after implementation changes in bug 1945672
Bug: Tab groups in "Recently closed tabs" should have a solid fill favicon colour
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2025-02-06 19:32:59+00:00
Resolved: 2025-03-05 14:40:51+00:00

**Steps to reproduce [can add screenshots or video recordings for reference]:**

1. Create a tab group and delete it
2. Go to "Recently closed tabs" in the Application menu or the system menu


**Expected behavior [What should have happened?]:**
Tab group favicon should be a solid fill


**Actual behavior [What actually happened?]:**
Tab group favicon is an outline fill
Bug: Consider using favicons added after pageshow is nothing else is available
Status: NEW
Priority: P5
Created: 2025-02-06 20:41:03+00:00
Resolved: 2025-02-07 11:09:12+00:00

Treeherder bookmarks do not show the faviconand instead show the default no-favicon icon.

Treeherder does not have a favicon at /favicon.ico:

```
~ $ curl -S https://treeherder.mozilla.org/favicon.ico
<!doctype html><html lang="en"><head><meta charset="utf-8"/><title>Treeherder</title><link rel="stylesheet" href="https://stackpath.bootstrapcdn.com/bootstrap/4.4.1/css/bootstrap.min.css" integrity="sha384-Vkoo8x4CGsO3+Hhxv8T/Q5PaXtkKtu6ug5TOeNV6gBiFeWPGFN9MuhOf23Q9Ifjh" crossorigin="anonymous"/><script defer="defer" src="/assets/runtime.a1680134.js"></script><script defer="defer" src="/assets/redoc.22427908.js"></script><script defer="defer" src="/assets/365.97bbc401.js"></script><script defer="defer" src="/assets/index.c4e180ce.js"></script><link href="/assets/index.44deacda.css" rel="stylesheet"></head><body><div id="root"></div></body></html>⏎
```

Instead it uses react-helmet to add a favicon to the page (href truncated)
```
<link rel="Treeherder Jobs View icon" href="data:image/png;base64,iV…1O/M1vwsAAAAAElFTkSuQmCC" data-react-helmet="true">
```

Maybe the rel= here is confusing something and preventing the bookmark from showing the icon? The tab correctly shows this icon.
Bug: Reversed icons in "Forget" panel
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-02-06 23:02:09+00:00
Resolved: 2025-02-07 07:23:59+00:00

Steps to reproduce:

* Open the [Customize Firefox GUI](https://support.mozilla.org/kb/customize-firefox-controls-buttons-and-toolbars) and add the `Forget` button to your toolbar
* Press it


Actual results:

The icons for "Delete Recent History" and "Open a new clean Window" are reversed. These labels also use an inconsistent capitalization.
Bug: Folder expansion can mean that the busy dialog isn't shown until it is done
Status: NEW
Priority: --
Created: 2025-02-06 23:19:54+00:00
Resolved: 2025-02-06 23:19:54+00:00

When Content Analysis is asked to analyze a folder, no `ContentAnalysisRequest` is submitted (to the agent or the UI) until the folder expansion is done.  This includes a delay for the busy DLP dialog, which is used to block access to the page during that period.  Currently, [this](https://searchfox.org/mozilla-central/rev/46c5f46a83146b311828b9cdd64b975a08066278/toolkit/components/contentanalysis/ContentAnalysis.cpp#1725-1730) is where we expand a request with a folder into multiple file requests -- `MaybeExpandAndAnalyzeFolderContentRequest` uses `GetFilesHelper` with a callback and [issues new requests when the callback is called](https://searchfox.org/mozilla-central/rev/46c5f46a83146b311828b9cdd64b975a08066278/toolkit/components/contentanalysis/ContentAnalysis.cpp#1550-1554).  As seen in the linked code, it also returns before sending the dlp-request-made message that starts the busy dialog.  We can expect this to be brief but it would be good to fix the UI code so that we can alert it without a finalized request.

This behavior is part of the refactor going on in bug 1936020, but that refactor doesn't fix this issue.

We can probably just send the dlp-request-made/dlp-response messages for the non-final requests as well.  ContentAnalysis.sys.mjs would need to be made robust to these messages -- it wouldn't be able to base the text contents on the request (or would have to be made smarter about doing so).  That non-final request dialog would then be dismissed when the final requests arrive.
Bug: Vertical pinned tabs can be closed by clicking the top left corner
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2025-02-07 00:03:59+00:00
Resolved: 2025-02-12 16:35:28+00:00

I keep accidentally closing my pinned tabs and I finally realized that even though there is no X icon on hover for the pinned tabs, they still close when you click there.
Bug: Unable to pair a mobile device using firefox.com/pair - "error while creating the pairing channel" or "can't access dead object"
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2025-02-07 00:12:15+00:00
Resolved: 2025-02-08 21:33:54+00:00

STR:
1. In a fresh profile on Firefox for desktop, visit `about:preferences#sync` and sign in to Firefox.
(Or you can use an already-signed-in firefox; I'm just starting with a fresh profile for clean-slate reproducibility)
2. (optional) Be sure to close any Firefox Settings tabs to avoid possibly hitting bug 1942333.
3. Open Firefox on an Android device which is *not yet signed in to sync*, and go to "Settings | Sync | Sync and save your data", and tap "ready to scan", which opens a QR code scanner.
4. Back on your desktop machine, visit https://firefox.com/pair and choose "I already have firefox for mobile" and click continue. This should show you a QR code.
5. Scan the qr code (with the scanner that you opened in step 3)

ACTUAL RESULTS:
The pairing fails at this point in one of the following ways -- either:
(A) My desktop Firefox stays on the settings page (seemingly recognizing that it's been scanned), and my mobile phone navigates to a "Device pairing failed" page with a red area showing "Error while creating the pairing channel"
...OR:
(B) Things look like they worked and my Desktop firefox session loads a 2fa screen for my Firefox Account for a second, but then immediately redirects to a "Device pairing failed" page with the following content:
```
can't access dead object
The setup couldn’t be completed. Please sign in with your email.
```

EXPECTED RESULTS:
Successful pairing.

This is a recent regression -- this is the regression range I got with mozregression:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=00c5cf0b1b4f1ec0c03f0189886fd21ce8800805&tochange=e9c90fbcc514b3caca3be1cd733e7ed79f4fdf84

which just has two commits from Arai, unseeting and then removing `deoptimizeModuleGlobalVars` in bug 1941472 and bug 1938859.  Assuming the regression range is correct, this would probably be proximally a regression from the first one (the one that unsets the variable) --> marking as such.
Bug: V135 "New tab" icons are now way smaller
Status: NEW
Priority: --
Created: 2025-02-07 00:18:42+00:00
Resolved: 2025-03-04 03:56:58+00:00

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

Steps to reproduce:

Update Firefox to 135


Actual results:

When "New tab" (CTRL+T) is opened, all the 4 rows of favourite sites pinned at the center of the screen looks twice as smaller than before


Expected results:

The icons shouldn't be reduced, or at least have an option to choose the size while keeping the number of icons per column/row
Bug: QR Code spinner-graphic is off-center, in firefox desktop's mobile-sync pairing flow
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2025-02-07 00:40:47+00:00
Resolved: 2025-03-05 14:38:46+00:00

STR:
1. Be using a Firefox session that's signed in to sync.
2. (optional) close any Firefox settings tabs, or you might be tripped up on bug 1942333.
3. Visit https://firefox.com/pair/ and click "I already have Firefox for mobile" and then "Continue"
4. Watch carefully as the QR code renders.

ACTUAL RESULTS:
There's a loading spinner/throbber as the QR code comes up, and that spinner is positioned at an awkwardly off-center spot.

EXPECTED RESULTS:
Spinner should be nicely centered.

Note: Even after the spinner has disappeared, you can bring it back manually in devtools to see it -- it's
```
<box xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" id="qrSpinner"/>
```
The actual rendered thing there is a ::before pseudo-element with a centered background. It's got a CSS animation playing, but if I pause that animation, I can see the issue -- it's got the correct size, but it's at the wrong x-position.

It's got the wrong x-position because there's a size mismatch -- `qrSpinner` is larger than its container and overflows equally off the left and right side -- and so `qrSpinner`'s ::before pseudo-element-child is offset to the left as a result of that.
Bug: Poor translation quality with new lines in the text
Status: NEW
Priority: --
Created: 2025-02-07 01:13:05+00:00
Resolved: 2025-03-03 22:48:04+00:00

When translating the first paragraph of this website https://www.freebsd.org/ from English to Russian it produces nonsense. When I copy the text to about:translations it's perfect. I edited the HTML to remove new lines from the text and the quality of translation became good. 

Does it make sense to remove new lines inside paragraphs before translating to prevent such cases?

> FreeBSD is an operating system used to power modern servers,
desktops, and embedded <a href="https://www.freebsd.org/platforms/">platforms.</a> A large
<a href="https://docs.FreeBSD.org/en/articles/contributors/#staff-committers">
community</a> has continually developed it for more than thirty
years. Its advanced networking, security, and storage features have
made FreeBSD the platform of choice for many of the <a href="https://docs.FreeBSD.org/en/books/handbook/introduction/#introduction-nutshell-users">
busiest web sites</a> and most pervasive embedded networking and
storage devices.
Bug: Panic button: icons for "Open a new clean Window" and "Delete Recent History" are backwards
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2025-02-07 06:52:26+00:00
Resolved: 2025-02-25 13:23:51+00:00

Icons are coming from chrome://browser/skin/panic-panel/icons.png

I assume this was regressed by bug 1853652.
Bug: Brief flickering when opening Unified Search Button Dropdown
Status: NEW
Priority: P3
Created: 2025-02-07 08:34:20+00:00
Resolved: 2025-02-26 14:28:31+00:00

**Notes** 
* The issue can be see in the attachment, the flickering happens as the first letter of local_search engines is updated to uppercase. 

**Found in**
* Beta 136.0b2;

**Affected version**
* Beta 136.0b2;
* Nightly 137.0a1; 

**Affected platforms**
* Windows 10;
* Ubuntu 22;

**Steps to reproduce**
1. Launch Firefox.
2. Open the Unified Search Button.
3. Observe the USB dropdown.
  
**Expected result**
* No flickering.

**Actual result**
* Split second flickering for Bookmarks/Tabs/History/Actions items as the lowercase letter is updated to uppercase. 

**Regression range**
* last good: 2024-12-03
* first bad: 2024-12-04
* pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=1bc8e62c38ee0cd9fae105403dc6c2a917c7908a&tochange=f87ae76c3a5fbbb92e5e96d7233dea1944baa4fe
* potentially regressed by: bug 1932106
Bug: Newtab shortcuts darkmode hover without background wrong color
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2025-02-07 09:05:44+00:00
Resolved: 2025-02-14 09:59:45+00:00

Reproduce:
Hover a shortcut without any wallpaper, see the background color of the hover state.
Current color : var(--newtab-element-hover-color)

Add a wallpaper and hover a shortcut, see the background color of the hover state.
Current color:  var(--newtab-weather-background-color)

Expected behavior:
With and without wallpaper, shortcuts have the same bg color for hover:  var(--newtab-weather-background-color)
Bug: Hiding the sidebar in horizontal mode is not smooth and the buttons are still displayed for a split second after the sidebar is hidden
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2025-02-07 09:26:03+00:00
Resolved: 2025-02-13 14:00:30+00:00

**Found in**
* 137.0a1 (2025-02-07)



**Affected versions**
* 137.0a1 (2025-02-07)









**Tested platforms**
* Affected platforms:  Windows 10x64, macOS 12, Ubuntu 24
* Unaffected platforms: none

**Preconditions**
* sidebar enabled
* horizontal tabs enabled

**Steps to reproduce**
1. Click to hide the sidebar and observe the buttons.


****Expected result****
* The sidebar is closed smoothly and the buttons are not displayed after the sidebar is closed.

**Actual result**
* The sidebar is closed instantly and the buttons are still displayed for a split second.


**Regression range**
* https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=492b20343145aed38aa28b5afaf0879d78167c01&tochange=c540eb5c0a914002537794fae4e26a727cc60dd5 
Potential regressor: bug 1930201. Feel free to change it if this is incorrect. Thank you!

**Additional notes**
* Attached a screen recording.
Bug: The sections cards from it, fr, es locales remain stuck in a continuous loading state when the “browser.newtabpage.activity-stream.discoverystream.sections.enabled” pref is enabled
Status: NEW
Priority: --
Created: 2025-02-07 10:40:30+00:00
Resolved: 2025-02-07 10:40:30+00:00

**[Notes]:**
- This issue is not reproducible on us, de locales. 

**[Affected versions]:**
- Firefox Beta 136.0.2 - Build ID: 20250205091800
- Firefox Release 135 - Build ID: 20250130195129
- Firefox Nightly 137.0a1 - Build ID: 20250207014520


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


**[Prerequisites]:**
- Have the Firefox Beta 136.0.2 it/fr/de build installed.
- Have the VPN set to the previous chosen locale. (IT, FR or ES).

**[Steps to reproduce]:**
1. Open the browser from the prerequisites.
2. Navigate to the “about:config” page and set “browser.newtabpage.activity-stream.discoverystream.sections.enabled” to true.
3. Restart the browser and open a new tab.
4. Observe the section cards from the new tab.

**[Expected result]:**
-  The cards from the new tab are loaded.

**[Actual result]:**
- The cards from the new tab are not loaded.

**[Additional Notes]:**
- A video of this issue is attached [here](https://drive.google.com/file/d/1HCHchOD6D9YSBSi5EelwXtF8UAhWhllA/view?usp=sharing).
Bug: Animations are glitchy for "hide sidebar" and "expand on hover" settings
Status: RESOLVED
Priority: P1
Resolution: DUPLICATE
Created: 2025-02-07 10:59:57+00:00
Resolved: 2025-02-07 15:36:23+00:00

In latest Nightly and central, animations are glitchy on latest Nightly 137.0a1 and latest central when you select "Hide tabs and sidebar" and click the sidebar toolbarbutton to close it. And with expand on hover enabled, its worse.
Bug: JSON view shows MAX_LONG incorrectly
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-02-07 11:34:13+00:00
Resolved: 2025-02-07 11:37:23+00:00

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

Steps to reproduce:

Show this minimal JSON file in the JSON view:
[{"maxLongInteger":9223372036854775807}]

Note: That's 2^63-1, the largest possible value of a signed 64bit integer


Actual results:

JSON view shows 9223372036854776000 instead of 9223372036854775807. See attachment
This number is even bigger than MAX_LONG and doesn't fit into a 64bit-signed.
Raw Data view shows the correct value


Expected results:

Show the correct value in both views.