av9ash/GitBugs huggingface dataset:
Bug: [Rollout] The branch configuration of the HNT weather widget rollouts doesn't enable the weather widget
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2025-02-07 12:28:13+00:00
Resolved: 2025-02-18 11:01:11+00:00

**[Notes]**
- Even though we can successfully enroll in the rollouts, the weather widget is NOT displayed on the New Tab Page.
- However, if we manually set the `browser.newtabpage.activity-stream.discoverystream.region-weather-config` and
`browser.newtabpage.activity-stream.discoverystream.locale-weather-config` prefs with the configs set in the Experimenter page, the Weather Widget is correctly displayed.
- It seems that the "regionWeatherConfig" and "localeWeatherConfig" configs are not working.

**[Affected versions]:**
- Firefox Release 135.0 (Build ID: 20250130195129)
- Firefox Beta 136.0b2 (Build ID: 20250205091800)
- Nightly 137.0a1 (Build ID: 20250207045558)

**[Affected Platforms]:**
- Windows 10 x64
- MacOS 14.7.1
- Linux Mint 20.1

**[Prerequisites]:**
- Have a Firefox Beta 136.0b2 build installed/extracted.
- Have a VPN connection to one of the countries that the rollout targets (eg: Brazil)
- Have the Firefox browser language set to one of the locales that the rollout targets (eg: pt-BR).
- Have the following prefs set:
 - nimbus.debug = true

**[Steps to reproduce]:**
1. Open the browser with the profile from the prerequisites.
2. Force enroll in the rollout by navigating to the following link: about:studies?optin_slug=hnt-weather-with-location-selector-non-eu-expansion-romance-and-germanic-lang&optin_branch=control&optin_collection=nimbus-preview.
3. Open a new tab.

**[Expected result]:**
- The Weather Widget is displayed.

**[Actual result]:**
- The Weather Widget is NOT displayed.

**[Notes]:**
- The issue is reproducible with the 3 rollouts: [HNT weather with location selector non-EU expansion Indo-European](https://experimenter.services.mozilla.com/nimbus/hnt-weather-with-location-selector-non-eu-expansion/summary), [HNT weather with location selector non-EU expansion Asian Language Family](https://experimenter.services.mozilla.com/nimbus/hnt-weather-with-location-selector-non-eu-expansion-asian-language-family/summary), [HNT weather with location selector non-EU expansion Romance and Germanic Lang](https://experimenter.services.mozilla.com/nimbus/hnt-weather-with-location-selector-non-eu-expansion-romance-and-germanic-lang/summary).
- Attached is a screen recording of the issue.
Bug: Sidebar context menu initially shows "Turn on vertical tabs" even though vertical tabs are enabled
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2025-02-07 13:35:21+00:00
Resolved: 2025-03-05 13:36:22+00:00

after first right-klick in the tabs-sidebar the context-menu shows "Turn** on** Vertical Tabs" instead of "Turn **off **Vertical Tabs".
From the second right-klick on it´s shown correctly...
Bug: Saved tab groups appear in the TOM menu in private windows
Status: RESOLVED
Priority: P1
Resolution: DUPLICATE
Created: 2025-02-07 14:22:51+00:00
Resolved: 2025-02-11 15:54:55+00:00

STR:
1. In a non-private window, open some non-about:blank tabs. Add them to a tab group.
2. Right click the tab group label and click "Save and close group".
3. Open a private window.
4. Open the tab overflow menu.

Expected result:
- No saved groups appear.

Actual result:
- The saved group appears.

Additional context:
It is not possible to actually restore the tab group to the private context since this is blocked at the session restore API level. This is a purely UI issue.
Bug: It is possible to save a tab group in private browsing mode and restore it in non-private mode
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2025-02-07 14:28:46+00:00
Resolved: 2025-03-05 14:41:20+00:00

STR:
1. Open two windows, one private and one non-private.
2. In the private window, open a few non-about:blank tabs and add them to a tab group.
3. Right click the tab group label and click "Save and close group."
4. In the non-private window, open the tab overflow menu.
5. Click the tab group that appears.

Actual result:
- The tab group is restored.

Expected result:
All steps from 3 onward should be impossible. The "save and close group" dialog should be disabled in private windows.

Notes:
This should probably be disabled also at the API level. I feel it's necessary to be extra sure it's impossible for tabs to cross the private/non-private boundary.
Bug: The contextual feature recommondation had a visual glitch for me, hiding the "Dismiss" / "Sync to mobile" button (DESKTOP_TO_MOBILE_ADOPTION_SIGNED_INTO_ACCOUNT_EU)
Status: NEW
Priority: P3
Created: 2025-02-07 15:14:39+00:00
Resolved: 2025-02-24 18:18:04+00:00

I can't reproduce, but took a screenshot at the time. When activating the CFR via `about:asrouter`, then the buttons show up properly (not sure if and how to reproduce). I dismissed CFR with Esc and slight annoyance that there is no `x` (reason I took the screenshot). However, it turns out the Dismiss button was just not rendered for me.

DESKTOP_TO_MOBILE_ADOPTION_SIGNED_INTO_ACCOUNT_EU

I'm on Linux, GNOME 47, X11. So might be platform specific, but who knows :/.

Reporting to let you know that this might be a problem for others too.
Bug: Try it now doesn't work for Edit PDFs in Firefox.
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-02-07 17:02:26+00:00
Resolved: 2025-02-08 17:09:52+00:00

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

Steps to reproduce:

Clicked on "Try it now" for Edit PDFs in Firefox webpage:

https://www.mozilla.org/en-US/firefox/135.0/whatsnew/?oldversion=134.0.2&utm_medium=firefox-desktop&utm_source=update&utm_campaign=135


Actual results:

Couldn't edit the blands where it suggested I add a name, a date, etc.  When clicking on the blank areas, the cursor did not change.  Typing had no effect.


Expected results:

The cursor shold have changed and started blinking in the blank fields to be filled in to test out the editing ability.
Bug: Intermittent [TV] browser/components/urlbar/tests/browser-tips/browser_picks.js | Test timed out -
Status: NEW
Priority: P5
Created: 2025-02-07 17:14:28+00:00
Resolved: 2025-02-10 17:34:57+00:00

**Filed by:** smolnar [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=493863285&repo=autoland
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/JO0m9XhlRZi7LviqT1megw/runs/0/artifacts/public/logs/live_backing.log
**Reftest URL:** https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/JO0m9XhlRZi7LviqT1megw/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1

---
```
INFO - Buffered messages finished
[task 2025-02-07T16:09:14.017Z] 16:09:14     INFO - TEST-UNEXPECTED-FAIL | browser/components/urlbar/tests/browser-tips/browser_picks.js | Test timed out - 
[task 2025-02-07T16:09:14.017Z] 16:09:14     INFO - GECKO(31987) | Completed ShutdownLeaks collections in process 31987
[task 2025-02-07T16:09:14.017Z] 16:09:14     INFO - TEST-START | Shutdown
[task 2025-02-07T16:09:14.018Z] 16:09:14     INFO - Browser Chrome Test Summary
[task 2025-02-07T16:09:14.018Z] 16:09:14     INFO - Passed:  3
[task 2025-02-07T16:09:14.018Z] 16:09:14     INFO - Failed:  1
[task 2025-02-07T16:09:14.019Z] 16:09:14     INFO - Todo:    0
[task 2025-02-07T16:09:14.019Z] 16:09:14     INFO - Mode:    e10s
[task 2025-02-07T16:09:14.019Z] 16:09:14     INFO - *** End BrowserChrome Test Results ***
[task 2025-02-07T16:09:14.019Z] 16:09:14     INFO - GECKO(31987) | Exiting due to channel error.
[task 2025-02-07T16:09:14.020Z] 16:09:14     INFO - GECKO(31987) | Exiting due to channel error.
[task 2025-02-07T16:09:14.020Z] 16:09:14     INFO - GECKO(31987) | Exiting due to channel error.
[task 2025-02-07T16:09:14.020Z] 16:09:14     INFO - GECKO(31987) | Exiting due to channel error.
[task 2025-02-07T16:09:14.021Z] 16:09:14     INFO - GECKO(31987) | Exiting due to channel error.
[task 2025-02-07T16:09:14.021Z] 16:09:14     INFO - GECKO(31987) | Exiting due to channel error.
[task 2025-02-07T16:09:14.021Z] 16:09:14     INFO - GECKO(31987) | Exiting due to channel error.
[task 2025-02-07T16:09:14.021Z] 16:09:14     INFO - GECKO(31987) | Exiting due to channel error.
[task 2025-02-07T16:09:14.022Z] 16:09:14     INFO - TEST-INFO | Main app process: exit 0
[task 2025-02-07T16:09:14.022Z] 16:09:14     INFO - TEST-UNEXPECTED-FAIL | browser/components/urlbar/tests/browser-tips/browser_picks.js | Application shut down (without crashing) in the middle of a test!
[task 2025-02-07T16:09:14.022Z] 16:09:14     INFO - TEST-INFO took 450583ms
```
Bug: Hiding close button for expand on hover hides it for all visibility settings
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2025-02-07 17:21:38+00:00
Resolved: 2025-02-14 05:01:16+00:00

A condition was [added](https://searchfox.org/mozilla-central/rev/b0b003e992b199fd8e13999bd5d06d06c84a3fd2/browser/themes/shared/tabbrowser/tabs.css#1404-1411) in bug 1930201 because we don't want the vertical tabs close buttons in the collapsed state for expand on hover, but it effectively hides the buttons for all visibility settings when this pref is enabled. So we'll need to fix this when we go live with this feature, and what would be nice is to do something like:

```
.tab-close-button {
  --moz-pref("sidebar.visibility", "expand-on-hover") {
     display: none;
  }
}
```
That support in style sheets doesn't exist though - only `--moz-bool-pref` - but Emilio said support could be added to it (see bug 1946764).
Bug: "Turn on Vertical Tabs" is too easy to accidentally trigger in its current position due to muscle memory
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-02-07 17:40:24+00:00
Resolved: 2025-02-08 07:16:17+00:00

The new "Turn on Vertical Tabs" option is in the same position on the tab context menu as "Reopen Closed Tab" used to be (at the bottom). As a result I've accidentally triggered it multiple times (which is especially annoying given how non-obvious it is to undo the change). The same problem applies to "Customise Toolbar" in the toolbar context menu but that option is less commonly used.

### Steps to reproduce
1. Have multiple tabs open.
2. Close a tab.
3. Open context menu on another tab and choose the last menu item (as you've been doing for decades when not using Ctrl-Shift-Tab).

### Actual results
My layout is messed up with no obvious way to revert it.

### Expected results
The most recently closed tab is reopened.

### Notes
After accidentally clicking this option (without reading it due to muscle memory) my tabs disappeared and a bunch of icons appeared on the left of my screen. I didn't immediately realise those were tabs until I right-clicked one. Clicking "Turn off Vertical Tabs" does not fully undo the change, it leaves the vertical toolbar open and does not remove the newly added sidebar button on the main toolbar.
Bug: First pinned tab in vertical tab bar is 2px smaller in height
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2025-02-07 17:43:39+00:00
Resolved: 2025-02-27 05:51:10+00:00

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

Steps to reproduce:

Pinned tab to pinned tab area with vertical tabs on.


Actual results:

The first pinned tab (with 5 others also pinned) has a reduced height compared to every other pinned tab. Browser toolbox shows a -2px difference in height on "Normal" UI density. Tried un-pinning and then re-pinning, no difference. Whichever pinned tab takes the first spot becomes reduced in height.


Expected results:

Pinned tabs in vertical tab mode show have the same height.
Bug: Context menu on vertical tab container has double divider
Status: ASSIGNED
Priority: P2
Created: 2025-02-07 17:46:12+00:00
Resolved: 2025-03-05 15:15:12+00:00

### Steps to reproduce
1. Enable vertical tabs.
2. Right-click a blank area below the New Tab button on the vertical tab toolbar.

### Actual results
There are two adjacent dividers between "Reopen Closed Tab" and "Turn off Vertical Tabs".
Bug: "Turn off Vertical Tabs" does not revert all changes made by "Turn on Vertical Tabs"
Status: RESOLVED
Priority: P2
Resolution: INVALID
Created: 2025-02-07 17:51:52+00:00
Resolved: 2025-02-18 21:26:29+00:00

### Steps to reproduce
1. Load Firefox with a new profile.
2. Right-click a tab and choose "Turn on Vertical Tabs".
3. Right-click a tab and choose "Turn off Vertical Tabs".

### Expected results
Firefox should look the same before and after toggling vertical tabs.

### Actual results
After the vertical tabs are toggled on and off, the mini-sidebar is now permanently shown and a sidebar button is added to the main toolbar.

### Notes
Given how easy this is to accidentally trigger, turning it off should be made completely frictionless.
Bug: Firefox closes all tabs without any reason
Status: UNCONFIRMED
Priority: --
Created: 2025-02-07 18:50:28+00:00
Resolved: 2025-02-25 23:30:47+00:00

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

Steps to reproduce:

I have possibly opened few tabs and then opened panoramaview's tab groups.


Actual results:

The browser unexpectedly close. After reopening it, there are no tabs open. Some of the tabs (up to some recent tab limit I guess) are present in closed tabs. Recently closed windows menu does not contain window with my tabs, so it's not that.

I have managed to make a backup of `previous.jsonlz4`. Using [this](https://www.jeffersonscher.com/ffu/scrounger.html) tool I have found that all the tabs are still present in the file as open in Window 1.

I have tried to replace `sessionstore.jsonlz4` with this backup and reopen Firefox. Tabs are still missing and present in "closed tabs" menu. The tabs are not present in "hidden tabs" menu (under arrow icon on top right of the screen), so they are not hidden by possibly buggy addon.

I have tried running `firefox -safe-mode` after restore, tabs are still missing.


Expected results:

In ideal world, tabs wouldn't disappear.

If I restore my sessionstore backup, I expect all the tabs from the sessionstore to be present, or at least some error message explaining the problem.
Bug: Skeleton UI does not show new sidebar+Vertical tabs layout
Status: NEW
Priority: P3
Created: 2025-02-07 19:29:54+00:00
Resolved: 2025-02-14 05:53:28+00:00

Steps to reproduce the problem:
- Configure firefox with both new Sidebar and Vertical tabs
- Setup a theme (in may case Dreamer - Bold)

What is the expected behavior?
- When restarting Firefox the skeleton UI is shown and it resembles the UI of the new sidebar+vertical tabs and my theme colors are honored

What went wrong? (see video)
- starts with full page white skeleton UI resembling horizontal tabs and a white background
- then it shrinks to smaller size also white
- then go back to full screen with my theme colors and no tabs layout
Bug: Remove "Turn on/off Vertical Tabs" in the tab context menu
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2025-02-07 20:14:40+00:00
Resolved: 2025-02-20 13:13:23+00:00

I've seen people complain ([1](https://forums.mozillazine.org/viewtopic.php?p=14991892#p14991892), [2](https://forums.mozillazine.org/viewtopic.php?p=14992050#p14992050)) about accidentally enabling vertical tabs when intending to reopen a closed tab, which used to be the bottom context menu item on the tab bar (now second to bottom). Presumably, its placement and it being a potentially relatively frequent action made it easy for people to build muscle memory for it. Is there a chance we move this new item to a better place in the menu?

I'd also argue that for the generic toolbar context menu, this option should move up so that "Customize toolbar..." is at the bottom. I think there's less of a memory muscle issue there, it's more about my mental model of these options and their semantic hierarchy.
Bug: Sidebar toolbar button can appear checked when the sidebar launcher is hidden
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2025-02-07 20:23:36+00:00
Resolved: 2025-03-05 14:42:10+00:00

You can get into a state when the sidebar button appears checked when the launcher is hidden, and unchecked when its visible. 

STR: 
- In a new profile, open about:preferences and check the "Show sidebar" checkbox. This enables the new sidebar and the `sidebar.revamp` pref. 
- Uncheck the same box to disable the feature. 
- Check it again to re-enable
- Manually click the sidebar toolbar button

ER: 
- The sidebar launcher hides and the button becomes unchecked - i.e. un-highlighted. Clicking it again should show the sidebar and leave the button checked/highlighted

AR: 
- The sidebar launcher hides and the button stays checked/highlighted. Clicking it again shows the sidebar but the button becomes unchecked.
Bug: Retire obsolete sync.totalDevices targeting attribute
Status: NEW
Priority: P2
Created: 2025-02-07 22:05:04+00:00
Resolved: 2025-02-26 17:15:04+00:00

Targeting attribute [`sync`](https://firefox-source-docs.mozilla.org/browser/components/asrouter/docs/targeting-attributes.html#sync) returns an object with three properties:

```js
{
  desktopDevices: 1;
  mobileDevices: 1;
  totalDevices: 0;
}
```

As you can see, `totalDevices` does not work. It [requests](https://searchfox.org/mozilla-central/rev/bc00d156c8a5452689cd66cbce30fe10c6594977/browser/components/asrouter/modules/ASRouterTargeting.sys.mjs#99-104,641) the value of a pref that [no longer exists](https://searchfox.org/mozilla-central/search?q=sync.numClients&path=&case=false&regexp=false).

As far as I can tell, there is no pref tracking the total number of devices. But it's unnecessary to have one, since the total number of devices is simply the number of desktop devices plus the number of mobile devices. We don't need to include a property for that, since the two can be added together with JEXL if necessary: `sync.desktopDevices + sync.mobileDevices`

Since it's a potential footgun and redundant with the addition operator, I recommend we remove `totalDevices` and any related references to `syncNumDevices` and `sync.numDevices`.
Bug: white space can't be removed from toolbar
Status: UNCONFIRMED
Priority: --
Created: 2025-02-07 22:16:53+00:00
Resolved: 2025-03-06 00:11:59+00:00

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



Actual results:

The space from the toolbar can't be removed.
Bug: version 135 crashes on startup
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2025-02-07 22:28:17+00:00
Resolved: 2025-02-19 06:04:30+00:00

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

Steps to reproduce:

Starting sometime in the last month firefox crashed on startup for some profiles (I use many different profiles).  Starting when I upgraded to version 135 all profiles crash on startup.  I do have a user.js that is based on arkenfox on GIT.  I also have a hardened system, I do not allow code to run in appdata or any user modifiable folder.  I use no extensions and I do not use DRM which I know will not work on such a system.


Actual results:

On the first startup of version 136 it crashed.  I retried and it crashed again.  I tried other profiles, they all crashed.  I tried to create a brand new profile.  It also crashed.  I uninstalled and then installed version 134 (I have setup files all the way back to version 68).  I then tried using one of my profiles, it crashed.  I then deleted the entire mozilla folder in appdata/roaming.  I then started and created a brand new profile, I copied my user.js in.  It worked.  I then tried using a different profile (I copied all my profiles to another location before doing the delete)  It started but the tab crashed.  I then upgraded to verion 135.  Tried using the new profile just created in version 134.  It crashed.  I then created a new profile and didn't copy my user.js.  It crashed.  I allowed some of these crashes to send data to Mozilla . I have attached my user.js.  The problems are only in Windows.  I am submitting this under linux which runs fine.  


Expected results:

I expected it to work.  The upgrade to 135 caused profiles that used to work under 134 to crash, even after going back to 134.  I expect something was messed up in the registry.  Please let me know if there is any other data or anything else you want me to try.  I am a long time Firefox user and I would hate to have to switch to another browser.
Bug: Name of dialog/frame incorrectly exposed to VoiceOver
Status: NEW
Priority: --
Created: 2025-02-08 01:29:53+00:00
Resolved: 2025-02-24 20:17:14+00:00

STR:
1. From mobile "Download & go!" popup (anchored to user icon, appeared on restart for me), select "Sync Mobile" button which spawns the attached dialog in about:preferences
2. Navigate the dialog using VO+next

Expected: 
VoiceOver navigates the text content 


Actual:
VoiceOver moves from the close icon to an unknown "frame" object titled "chrome://browser/content/preferences/fxaPairDevice.xhtml". It isn't obvious this frame object is a dialog, nor that it has additional content in it. 

Please verify the role for this dialog is correct and that a human readable name is presented when users land on it.
Bug: Couldn't download translate packs
Status: UNCONFIRMED
Priority: --
Created: 2025-02-08 05:25:27+00:00
Resolved: 2025-02-24 12:19:16+00:00

Steps to reproduce:

I live in China, firefox couldn't download translate packs, I found that 34.149.100.209 has been blocked by gov's ensorship firewall, I also found that it is the IP of prod.remote-settings.prod.webservices.mozgcp.net, i.e. firefox.settings.services.mozilla.com. This bug could reproduce on Debian 12 vm with latest firefox. 



Expected results:

This bug should be solved, because it will prevent user in China using Firefox translate. Maybe need to add some alternate servers which IP hasn't blocked in china.
Bug: Since the update, my search engine hace disapeared
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-02-08 13:05:31+00:00
Resolved: 2025-02-17 11:34:49+00:00

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

Steps to reproduce:

I uptated to the last version


Actual results:

The search engine are gone


Expected results:

I should still have acces to the recorded search engine
Bug: Symbols in PDF not displaying
Status: NEW
Priority: P3
Created: 2025-02-08 14:36:23+00:00
Resolved: 2025-02-26 13:20:34+00:00

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

Steps to reproduce:

Open a PDF 'route notes' generated by ridewithgps.com 

Browser & Mobile


Actual results:

Black place holders displayed where the symbols should be


Expected results:

Symbols displayed.
As everything else does inc Windows, Chrome, Edge. SumatraPDF etc
Bug: Address bar losing focus
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-02-08 14:49:14+00:00
Resolved: 2025-02-22 05:40:42+00:00

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

Steps to reproduce:

Press alt+D to get to the address bar


Actual results:

The suggestions drop down opens, but the address bar has lost focus. You cannot type, nor you can use the cursor keys to select any suggestion


Expected results:

The focus should be inside the address bar
Bug: Symbols in PDF not displaying
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-02-08 16:05:30+00:00
Resolved: 2025-02-19 12:39:39+00:00

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

Steps to reproduce:

Open a PDF 'route notes' generated by ridewithgps.com 

Browser & Mobile


Actual results:

Black place holders displayed where the symbols should be


Expected results:

Symbols displayed.
As everything else does inc Windows, Chrome, Edge. SumatraPDF etc

This has been happening for a long time.