av9ash/GitBugs huggingface dataset:
Bug: Avoid setting the active pref when using the migrated sidebar
Status: NEW
Priority: P2
Created: 2025-01-24 01:30:11+00:00
Resolved: 2025-02-05 21:58:08+00:00

In the current RC, we determine visibility via our active pref. In the migrated RC, visibility is instead determined by `SidebarController`. We don't want to unnecessarily update the pref with the migrated RC if it's inapplicable.

We update the pref here: https://searchfox.org/mozilla-central/rev/55706b888f91fffa6f045f7cbc1a7b1c34598292/browser/components/shopping/content/settings.mjs#56-58

It's possible that I missed more cases when the active pref is set and we forget to check for the integratedSidebar pref. Let's double check for such cases when fixing the bug.
Bug: Intermittent browser/components/search/test/browser/telemetry/browser_search_glean_serp_event_telemetry_categorization_enabled_by_pref.js | single tracking bug
Status: NEW
Priority: P5
Created: 2025-01-24 01:36:22+00:00
Resolved: 2025-03-03 06:44:30+00:00

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

---
```
[task 2025-01-23T23:46:10.324Z] 23:46:10     INFO - TEST-PASS | browser/components/search/test/browser/telemetry/browser_search_glean_serp_event_telemetry_categorization_enabled_by_pref.js | serpEventsCategorizationEnabled should be true when the pref is true. - true == true - 
[task 2025-01-23T23:46:10.325Z] 23:46:10     INFO - Load a sample SERP with organic results.
[task 2025-01-23T23:46:10.325Z] 23:46:10     INFO - Buffered messages finished
[task 2025-01-23T23:46:10.326Z] 23:46:10     INFO - TEST-UNEXPECTED-FAIL | browser/components/search/test/browser/telemetry/browser_search_glean_serp_event_telemetry_categorization_enabled_by_pref.js | Test timed out - 
[task 2025-01-23T23:46:10.327Z] 23:46:10     INFO - GECKO(920) | Completed ShutdownLeaks collections in process 920
[task 2025-01-23T23:46:10.327Z] 23:46:10     INFO - TEST-START | Shutdown
```
Bug: Since 23/24Jan2025, typing "and" in the addressbar is auto-suggesting a website that I have visited only once, ignoring the site i visit many times daily
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-01-24 02:22:00+00:00
Resolved: 2025-01-24 09:52:57+00:00

Use my normal profile
Type "an" in the address-bar

AR: Firefox suddenly started suggesting "https://www.androidauthority.com/". This is a website that I have visited only once as per Firefox history.
ER: Firefox should suggest the [website ](https://bugzilla.mozilla.org/page.cgi?id=user_activity.html&action=run&from=-14d&who=andrebargull%40googlemail.com)that I visit many times daily

Note that "https://www.androidauthority.com/" is a bookmark.
Bug: ClearURLs add parameters (sclient=gws-wiz-serp) to search when using question marks (?)
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2025-01-24 11:42:41+00:00
Resolved: 2025-01-24 13:08:09+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 Firefox Version 134.0.2 (64-bit)
using google/bing search bar
Type something with question mark symbol (?) at the end example "test?"



Actual results:

in google "test?sclient=gws-wiz-serp"
in bing "test?lq=0"
seems to append parts of the url


Expected results:

should just "show" test in both.
Bug: Can't drag a tab from another window into a group
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2025-01-24 14:09:38+00:00
Resolved: 2025-03-05 07:06:27+00:00

STR

1. Have tab groups enabled
2. In a browser window, set up an open tab group with at least two tabs.
3. Open a new window, and open a couple of tabs and load pages.
4. Attempt to drag one of the tabs into the middle of the group in the first window.

Expected Results

The tab is added to the group and placed in location where you dropped it.

Actual Results

The tab is not added to the group, instead it is inserted into the window before the start of the tab group.
Bug: Bookmarks popup automatically closes too soon
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-01-24 15:03:08+00:00
Resolved: 2025-01-24 15:42:36+00:00

The "Bookmark this page" popup times out after 3.5 seconds which is not sufficient for any action to be taken and to even read the dialog. This issue would especially affect user with cognitive and developmental disabilities, dyslexia, and would make the interaction with Bookmarks extremely cumbersome for users with limited mobility, with or without any assistive technology running (i.e. those who rely on keyboard alone to navigate and interact with page). These users would have to find a way to re-open the dialog, while there is no indication what could happen, maybe the bookmark would be duplicated, etc.

This is an [access-S3 issue](https://wiki.mozilla.org/Accessibility/Triage) because while the feature is available, it is difficult to be used, really bordering the `access-S2` severity for some groups of users who may find it too difficult to use and would not have access to the extended management of bookmarks like their organization at the moment of bookmark creation.

WCAG 2.2 provides the following options to satisfy the [Timing Adjustable success criterion (Level A)](https://www.w3.org/TR/WCAG22/#enough-time): 
1. **Extend** - The user is warned before time expires and given **at least 20 seconds** to extend the time limit with a simple action (for example, "press the space bar"), and the user is allowed to extend the time limit at least ten times. [20 seconds time frame is taken from the clinical research by the WCAG authors and this is considered to be a generally sufficient time for a user to do one action](https://www.w3.org/WAI/WCAG22/Understanding/timing-adjustable.html#intent); or
2. **Turn off** - The user is allowed to turn off the time limit before encountering it; or
3. **Adjust** - The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting.

Note: options 2 "Turn Off" and 3 "Adjust" are expected to be provided on the same screen as the action, so adding a preference _would not resolve the issue_, unless a user would be offered, for instance, to check an option on the Add Bookmark popup to auto-close it (opt-in to the timeout), if they choose to do so. Adjusting may be in a form of a dialog offering to extend the timeline, but it does not seem like a delightful pattern here, in my opinion.

The Accessibility team will be happy to discuss possible solutions.
Bug: Color options on the tab group panel lack tooltips
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2025-01-24 17:11:13+00:00
Resolved: 2025-02-10 10:02:33+00:00

The color options have accessible names that provide a clarity for users of assistive technology on what are the options and how to refer to them. But for the users without assistive technology, including users with cognitive and developmental disabilities, low vision, or users who are less proficient in English and the color names, there is no visual reference beyond the color of the item. For instance, the "cyan" may not be as apparent of a choice of the color name. 

Since assistive technology like Voice Access (Win) would be able to ask the tool to show the names, they would be able to call them to activate, it could still be beneficial for users without any assistive tech to preview the name of the color. For instance, a user with color deficiency may clarify which color they would like to select, while helping their less tech savvy friend to set up their tab groups.
Bug: Survey X icon z-index is higher than the shopping-container sticky header
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2025-01-24 18:09:53+00:00
Resolved: 2025-03-04 05:01:36+00:00

STR:
1. Make sure to set these prefs as the following:
- browser.shopping.experience2023.survey.enabled = true
- browser.shopping.experience2023.survey.hasSeen = false
- browser.shopping.experience2023.survey.optedInTime to a smaller integer value (ex. 100) for the sake of testing
- browser.shopping.experience2023.survey.pdpVisits = 5

2. Then, go to a PDP that already has analysis results (ex. https://www.amazon.com/dp/B08D66HCXW)
3. The survey should then hopefully appear on Review Checker
4. Scroll down so that the survey is close to the top of the Review Checker container

Expected:
Survey X icon should be underneath the Review Checker header

Actual:
Survey X icon is above the header and is too close to the container's own X icon
Bug: Firefox drops previous session on update
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-01-24 18:12:30+00:00
Resolved: 2025-02-24 16:40:30+00:00

I'm reporting this for a friend so I don't have all the details at the moment, but my understanding is that a background update to v134.0.2 dropped the previous session so they lost all of their tabs.
Apparently, the history contains last session, but this is only if he doesn't close the update window (new window?).
This is on Windows10.
Bug: Keep closed message appears on opt-in UI empty state after turning off RC
Status: NEW
Priority: P2
Created: 2025-01-24 18:34:43+00:00
Resolved: 2025-02-07 02:39:11+00:00

STR:
1. For the sake of testing, set these prefs:
- browser.shopping.experience2023.showKeepSidebarClosedMessage = true
- browser.shopping.experience2023.survey.pdpVisits = 5
- browser.shopping.experience2023.autoOpen.enabled = true
- browser.shopping.experience2023.autoOpen.userEnabled = true

2. On a PDP, close RC using the X icon
3. The "keep closed" message should appear in RC
4. Instead of interacting with the message, go to the settings card and press the "turn off" button

Expected:
- The "keep closed" message disappears when the empty state is rendered

Actual:
- The "keep closed" message remains when the empty state is rendered

Notes:
- We render the message as a litelement template in our shopping-container: https://searchfox.org/mozilla-central/rev/f41e8cacb8e8ce254204e2526e98d49d024f1674/browser/components/shopping/content/shopping-container.mjs#599-612. Currently, we rely on a `showingKeepClosedMessage`, and we do not actually check the value of the `showKeepSidebarClosedMessage` pref again after opt-out.
- I'm curious if we can pass in `showingKeepClosedMessage: false` when we [detect the optIn state change and try to clear content](https://searchfox.org/mozilla-central/rev/f41e8cacb8e8ce254204e2526e98d49d024f1674/browser/components/shopping/ReviewCheckerChild.sys.mjs#262). The [reset function](https://searchfox.org/mozilla-central/rev/f41e8cacb8e8ce254204e2526e98d49d024f1674/browser/components/shopping/ReviewCheckerChild.sys.mjs#608-617) passes in several props to the shopping-container.
Bug: When topic management panel is enabled, toggling sections requires a page refresh
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2025-01-24 21:06:27+00:00
Resolved: 2025-01-25 09:43:15+00:00

### Setup: 

Set the follow prefs to `true`:
- `browser.newtabpage.activity-stream.discoverystream.sections.personalization.enabled`
- `browser.newtabpage.activity-stream.discoverystream.sections.customizeMenuPanel.enabled`
- `browser.newtabpage.activity-stream.discoverystream.sections.cards.enabled`

### Steps to reproduce: 
- Open up a new tab
- Either enable or disable Sections via about:config
- `browser.newtabpage.activity-stream.discoverystream.sections.enabled`
- Look at new tab page
- **Expected**: Should show/not show sections layout
- **Actual**: Displays Oops, something went wrong loading this content. message and requires page refresh

Error: 
```
TypeError: can't access property "components", state.DiscoveryStream.layout[0] is undefined
```

I suspect there's some if..else logic not being set correctly here: 
https://searchfox.org/mozilla-central/source/browser/components/newtab/content-src/components/CustomizeMenu/SectionsMgmtPanel/SectionsMgmtPanel.jsx#38-52
Bug: translationsParents in TranslationsEngineParent could be a memory leak
Status: NEW
Priority: --
Created: 2025-01-24 21:39:58+00:00
Resolved: 2025-02-27 20:52:56+00:00

From: https://phabricator.services.mozilla.com/D234907

> nika: Side-note which I noticed while working on the patch: This map appears to never be cleared during normal operations when translations actions are completed. This seems weird and potentially like leaky behaviour.

https://searchfox.org/mozilla-central/rev/5efa5bfe9c217f6ab3529880b25a52ac6405dda8/toolkit/components/translations/actors/TranslationsEngineParent.sys.mjs#21

They are deleted in `discardTranslations` but maybe we also need to clear it. It should be easy to investigate by logging the size of hte map and doing a bunch of translations across tabs and pages.
Bug: Investigate some potential races in engine shutdown
Status: NEW
Priority: --
Created: 2025-01-24 21:50:34+00:00
Resolved: 2025-02-17 17:17:35+00:00

See: https://phabricator.services.mozilla.com/D234907

> nika: FYI: I think this is potentially racy if there are multiple #onNewPortCreated methods running concurrently. There's no check that #engineDispatchers didn't change during the await currentEngineDispatcher.terminate call, and no way of handling multiple of these racing with one-another.

> nika: I moved this to be inline so that #engineDispatchers would be filled before the await happened, to ensure that this dispatcher can't be missed by calls to removeEngine or other similar functions. I think there are probably other potential races, but this one seemed like it could happen around shutdown and actor re-use, so I tried to fix it here (as actors are more likely to be re-used after these changes).
Bug: Long topsite titles containing CJK cause shift of contents of newtab on hover
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2025-01-25 12:37:00+00:00
Resolved: 2025-02-13 23:04:14+00:00

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

Steps to reproduce:

1. Change the title of a topsite in newtab to "모질라 파이어폭스".
2. Hover over it with the pointer.


Actual results:

The contents of the page (other topsite rows, pocket stories, etc) shift down (and/or up) when the full title is visible on hover.

The font used for CJK text on my system is "Noto Sans CJK 10pt (13px as reported in the devtools)", in case it's important. I wasn't able to find a way to reproduce it with any other writing system I tried.


Expected results:

This is a regression caused by 1868060. It, also, re-introduces Bug 1938231 in some cases.
Bug: Perma [tier 2] TEST-UNEXPECTED-TIMEOUT | browser/components/tabbrowser/test/browser/tabs/browser_navigatePinnedTab.js | application timed out after 370 seconds with no output - when Gecko 136 merges to beta on 2025-02-03
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-01-25 16:37:49+00:00
Resolved: 2025-01-31 10:29:59+00:00

[Central-as-beta-simulation](https://treeherder.mozilla.org/jobs?repo=try&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=8c5113df8faad69fa2f76ec3ea39454e466fab8a&selectedTaskRun=Jhb5z24eR4awUX2Ce96Gig.0)

[How to run these simulations](https://wiki.mozilla.org/Sheriffing/How_To/Beta_simulations#TRUNK_AS_EARLY_BETA)

[Failure log](https://treeherder.mozilla.org/logviewer?job_id=491821170&repo=try&lineNumber=32992)
Bug: huge context menu when right click on any page
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-01-25 20:22:55+00:00
Resolved: 2025-02-12 19:27:29+00:00

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

Steps to reproduce:

right click on any page


Actual results:

whenever I use the right click context menu the menu is huge, containing lots of items, most irrelevant to what I'm doing (such as "pause video" on a page with no videos)


Expected results:

context menu should only show relevant items
Bug: Firefox Screenshot Tool – Ctrl+C Only Works with English Keyboard Layout and Caps Lock Off
Status: NEW
Priority: P2
Created: 2025-01-25 23:44:26+00:00
Resolved: 2025-03-05 21:48:15+00:00

Steps to reproduce:

I have encountered a usability issue in Firefox’s Screenshot Tool, which affects users who do not use the English keyboard layout. Specifically, the Ctrl+C shortcut, which is used to copy the screenshot, only works if:

1) The keyboard layout is set to English (EN).
2) Caps Lock is turned off.

This means that users with a different keyboard layout (e.g.,: Russian, Arabic, etc.) cannot copy the screenshot using Ctrl+C unless they manually switch to the English layout and ensure Caps Lock is off, which is highly inconvenient.

Steps to Reproduce:

1) Open Firefox.
2) Take a screenshot using the Screenshot Tool.
3) Change the keyboard layout to any non-English language.
4) Press Ctrl+C to copy the screenshot.
5) Notice that nothing gets copied unless you switch back to the English layout.
6) Turn on Caps Lock while using the English layout and try again. Ctrl+C still does not work.

This breaks standard UX conventions and makes the Screenshot Tool frustrating for non-English users.

Every other major application (including Chrome, Edge, and system clipboard functions) allows Ctrl+C to work regardless of the keyboard layout or Caps Lock state.

It unfairly disadvantages international users by requiring them to switch their keyboard layout and disable Caps Lock just to perform a basic copy action.

Just a year ago, Mozilla removed the multi-select feature for folders in Thunderbird, another critical usability function that users relied on for years. The UX lead arbitrarily stated that not many people used it and locked the thread, preventing the few users who were aware of Bugzilla from even disagreeing.

After several months, frustrated users resorted to using the Mozilla forums to voice their complaints. Only after months of backlash did Mozilla decide to unlock the thread and fix the issue-but only after even more months had passed, during which users felt infuriated every time they needed to select more than one folder.

At a time when Mozilla’s market share is steadily declining, loyal users like us expect meaningful improvements, not the removal of core features. It is unacceptable that instead of making Firefox more competitive, basic functionalities we have relied on for years are being broken or removed.


Actual results:

The Ctrl+C shortcut in the Screenshot Tool does not work unless:
1) The keyboard layout is set to English.
2) Caps Lock is turned off.


Expected results:

The Ctrl+C shortcut should work in the Screenshot Tool regardless of the keyboard layout or Caps Lock state, just like it does in all other applications on Windows, Linux, and macOS.
Bug: "Basic Page Style" option no longer appears for sites using alternative stylesheets where the default stylesheet has no name (e.g. Advent of Code)
Status: NEW
Priority: --
Created: 2025-01-26 01:06:08+00:00
Resolved: 2025-01-27 17:39:52+00:00

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

Steps to reproduce:

1. Go to https://adventofcode.com/
2. Press alt
3. Select view -> page style -> High Contrast
4. Press alt
5. Select view -> page style


Actual results:

No option for "Basic Page Style" appears, and after selecting either of the other options, there is no way to return to the basic page style (other than navigating to another page and then navigating back, which does reset stylesheets; refreshing does not).


Expected results:

The "Basic Page Style" option should appear and be selected by default.

https://adventofcode.com/2024/about mentions that an alternative stylesheet is used to provide a high-contrast mode. See https://developer.mozilla.org/en-US/docs/Web/CSS/Alternative_style_sheets. Note that the example at https://mdn.github.io/css-examples/alt-style-sheets/ does not have this issue (as it provides a name for the default stylesheet).

This regressed in build 2023-02-25; build 2023-02-24 works. From https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=25a8668d92431d469b443f0f2030328bab754aea&tochange=adce45ea73836172c7ad0247a8de1acc3f5a2162 I assume it was the fix to bug 1818026 that caused this regression (as that directly touched this functionality).
Bug: Firefox resets window size with every new window
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2025-01-26 03:11:28+00:00
Resolved: 2025-02-05 23:03: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:

Launch Firefox. Or open a new Firefox window. Or take a tab from one window and split it off into its own window.


Actual results:

Every new window opens at a preset size of 1414×993, regardless of any custom size that was previously set by the user.

When a window is resized (by clicking the border and dragging to the desired size), Firefox is closed, and then relaunched, the new window briefly flickers at its designated custom size, but immediately resets to the new size of 1414×993.

When a window is set to a custom size, it remembers its size as long as it stays open, even when maximizing/restoring down/minimizing/full-screening/etc.
But the moment it is closed and a new window is opened, its size is reset to 1414×993.


Expected results:

Firefox should remember the last set custom size for new windows, as it has always done until update v134.0.2.
Bug: ClearURLs: Some SSO signing page is not working
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2025-01-26 04:22:21+00:00
Resolved: 2025-01-26 18:52:07+00:00

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

Steps to reproduce:

1. Open costco.com and click on sign in. It will be redirected to sign in page `https://signin.costco.com`
2. Once the credentials are filled, click on Sign In button
3. A spinner appears for a few seconds and disappear afterwards. 

Workaround: (credit to u/Karmirith)
1. Go to `about:config`
2. Search `extensions.webextensions.restrictedDomains` 
3. append `,signin.costco.com` to the end of existing values



Actual results:

We are stuck on the same sign in page


Expected results:

Sign in successful and redirect to costco.com page
Bug: Opening link in new tab won't show next to your current tab after moving tab with Ctrl+Shift+Page Up/Down.
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2025-01-26 07:49:11+00:00
Resolved: 2025-02-14 10:27:48+00:00

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

Steps to reproduce:

1. Open any link in new tab using the context menu or by middle clicking.
2. Move your current tab to the right with Ctrl+Shift+Page Down.
3. Open any link in new tab again.


Actual results:

The newly opened tab showed up next to the previously opened tab.


Expected results:

New tab show up next to your current tab.
Bug: Update to 134.0.2 from 133.0.3, on windows 10, 64 bit, loses min/max buttons
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2025-01-26 08:18:32+00:00
Resolved: 2025-01-27 06:30:31+00:00

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

Steps to reproduce:

downloaded and installed update to 134.0.2 from 133.03, on windows 10,64 bit.  After restarting browser, the min/max buttons are no longer appearing.


Actual results:

Lost the min/max buttons.  Still have the close button .


Expected results:

Min/max buttons should still be available as well as close button