av9ash/GitBugs huggingface dataset:
Bug: Rewind and volume sliders don't work on YouTube (caused by "Absolute Enable Right Click & Copy" extension)
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2025-02-08 16:15:14+00:00
Resolved: 2025-02-10 19:58:12+00:00

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

Steps to reproduce:

for Firefox ESR Version 115.20.0
====
on www.youtube.com the volume and rewind sliders don't work.
If you catch the volume slider with the cursor, you can move it with the mouse wheel


Actual results:

the volume and rewind sliders don't work


Expected results:

should work
Bug: TranslationsEngine fails to load due to "setTimeout is not defined"
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2025-02-08 16:29:03+00:00
Resolved: 2025-02-11 20:21:45+00:00

Steps to reproduce:

Try to translate any page. Language isn't important.


Actual results:

The translation fails with the displayed error being: "There was a problem translating. Please try again."


Expected results:

Regressed by Bug 1942128.

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=90f0b0004226da5025acc6f9b45d2d2371bf71cb&tochange=b95de61de7638546897604c446045ce42782b388
Bug: Clicking on the link for editing a pdf in Firefox opens a pdf in Acrobat.  ?
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-02-08 16:32:55+00:00
Resolved: 2025-02-08 17:06:51+00:00

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

Steps to reproduce:

Firefox automatically opened a page offering pdf editing directly in Firefox, but clicking on the button opens an info-pdf about it in Acrobat.  ?


Actual results:

Firefox automatically opened a page offering pdf editing directly in Firefox, but clicking on the button opens an info-pdf about it in Acrobat.  ?


Expected results:

I should have been taken, ostensibly, to the URL for editing PDFs in browser.
Bug: "Session restore" after "Close all windows" only restores 1 window, not ALL windows
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-02-08 19:54:48+00:00
Resolved: 2025-02-10 16:52:04+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 can reproduce by following these steps:

1) I clicked "Close all windows" via right-clicking on the Firefox in the Window's Start bar at the bottom of the screen.

2) 11 Firefox windows closed.

3) I reopened Firefox & it updated itself.

4) I clicked "Session Restore".

5) Only 1 of the 11 previously closed windows was restored. 

6) I clicked "Reopen all windows" via "Recently Closed Windows".

7) Only 4 more windows were restored, leaving a total of 6 of 11 windows unrestored.


Actual results:

As stated at step 5, Firefox only restored 1 window.

Therefore, I deduce that Firefox only deemed the last 1 of the 11 windows it closed when I clicked "Close all windows" to be part of my previous session.


Expected results:

Firefox should have restored all 11 windows.

To do that, Firefox should have identified all 11 windows as part of the same session.

After Firefox updated itself, I should have been able to use "Session Restore" to restore all 11 windows with all of their tabs.
Bug: Application hangs when trying to download a file after a while
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2025-02-09 12:31:05+00:00
Resolved: 2025-02-18 06:28:17+00:00

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

Steps to reproduce:

Save images from images.google.com via Save As dialog:

1. Open images in new tabs (like multiple 20-30)
2. For each tab, bring up "Save As" dialog, via context menu
3. Save the image
4. Press Ctrl+W to close the page

Repeat steps 1-4 within 10-20 minutes


Actual results:

After a while i tried to download next image, right after closing Save As... dialog, browser freezes and never responds, saving the file. Download icon on top right becomes just white circle, then UI does not update.


Expected results:

Files should have been saved, and Firefox should not have hang.
Bug: Manage Colors...  override setting nullified by: <meta name="color-scheme" content="light">
Status: UNCONFIRMED
Priority: --
Created: 2025-02-09 20:58:41+00:00
Resolved: 2025-03-05 01:35:28+00:00

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

Steps to reproduce:

Firefox settings> General tab> Language and Appearance> Website appearance: Dark
General tab> Colors> [Manage Colors...]
check the box: Use system colors  ( I have a dark setting )
Override the colors... Always



Actual results:

This successfully makes all websites have dark background and light text, except if the following line is in the <head> section:
<meta name="color-scheme" content="light">
I noticed this in some websites, can't remember, but a simple about:blank webpage can be edited to include this meta tag line and will show a light background.


Expected results:

The dark setting should still overrule the light color scheme setting.
Bug: Intermittent [tier 2] browser/components/customizableui/test/browser_palette_labels.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2025-02-09 22:09:05+00:00
Resolved: 2025-03-03 12:11:01+00:00

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

---
```
[task 2025-02-09T21:38:11.852Z] 21:38:11     INFO - TEST-PASS | browser/base/content/test/webrtc/browser_device_controls_menus.js | Should have found an appropriate display menuitem - "[object XULElement]" == true - 
[task 2025-02-09T21:38:11.852Z] 21:38:11     INFO - Buffered messages finished
[task 2025-02-09T21:38:11.852Z] 21:38:11     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/webrtc/browser_device_controls_menus.js | Test timed out - 
[task 2025-02-09T21:38:11.852Z] 21:38:11     INFO - GECKO(11713) | Completed ShutdownLeaks collections in process 11713
[task 2025-02-09T21:38:11.852Z] 21:38:11     INFO - TEST-START | Shutdown
```
Bug: Newtab shortcuts refresh shortcut titles are abbreviated at unhelpfully short length
Status: UNCONFIRMED
Priority: --
Created: 2025-02-09 23:05:07+00:00
Resolved: 2025-02-24 12:19:30+00:00

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

Steps to reproduce:

The shortcut titles on the new tab page are abbreviated after only 7 or 8 characters, and then only 4 characters are visible. This is so few characters as to be useless.

This is particularity noticeable with pinned shortcuts, as the pin icon takes up significant space.

Using Firefox 135.0 (64-bit) on Debian 12 from Mozilla deb repo.
Scaling set to 100% in GNOME Settings, on a 1920x1080 13.3 inch display.
Default font is DejaVu Sans at 16pt.


Actual results:

The titles displayed below shortcut items on the refreshed new tab page are abbreviated when they were not before. The abbreviation only leaves 4 characters visible, which defeats the point of having these titles shown. For example, and as shown in the attached image, even a shortcut to YouTube gets abbreviated.




Expected results:

The visible title length should be sufficient to show the names of common services. This may involve relocation the pin icon.
Bug: Translation gets confused by <ruby> elements
Status: NEW
Priority: --
Created: 2025-02-10 02:56:38+00:00
Resolved: 2025-02-27 12:15: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:

Open a page that uses <ruby> elements to show annotations over text. These are common in Japanese to show furigana (phonetic reading of a word or kanji). For example https://www3.nhk.or.jp/news/easy/ne2025020711556/ne2025020711556.html and notice that the translation of the title "9日まで　いつもは雪の降らない所でも気をつけて" is completely broken (it should be something like “Until the 9th, be careful even where it doesn't usually snow.”)


Actual results:

Translation gets extremely confused, seemingly translating each fragment of text between ruby elements in isolation, yielding a completely nonsensical translation: "9thUntil, usually.Snowの降 降No.所but...qi.Put it on."

For example in this html:

<ruby>9日<rt>ここのか</rt></ruby>まで　いつもは<ruby>雪<rt>ゆき</rt></ruby>の<ruby>降<rt>ふ</rt></ruby>らない<ruby>所<rt>ところ</rt></ruby>でも<ruby>気<rt>き</rt></ruby>をつけて

the translation seem to independently translate each of the text segments "9日", "ここのか", "まで　いつもは", "雪", ... 




Expected results:

What should have happened instead is that translation (at least in the case of Japanese furigana) should ignore the contents of the <rt> (annotation) tags, and instead translate "9日まで　いつもは雪の降らない所でも気をつけて" as a single phrase.

Note: it is quite possible that ignoring the furigana, while the simplest option, may not be the best one because furigana can be used to discriminate between the different meanings of the same kanji/word, or in some extreme cases even to layer additional meanings not actually present in the base kanji/word. Similarly, for annotations in other languages these annotations may be used for completely different reasons/functions, so ignoring them completely may also not be ideal.
Bug: After the page has been translated reverting to the original language reloads the page
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-02-10 03:05:07+00:00
Resolved: 2025-02-10 09:59:01+00:00

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

Steps to reproduce:

1) Open a page in a different language (e.g. Japanese), and translate it using local translation. 
2) Open the translation menu (translation icon in the address bar) and select show original


Actual results:

Page is reloaded, and shown in the original language


Expected results:

Page is NOT reloaded, all translated text reverts to the original language
Bug: Session recovery tab in restored session truncated when restarting Firefox for an update
Status: UNCONFIRMED
Priority: --
Created: 2025-02-10 03:17:40+00:00
Resolved: 2025-02-21 16:13:41+00:00

Steps to reproduce:

I had a "Restore previous session" tab open with a previous session. Then I updated. 


Actual results:

After the restart, the same "Restore previous session" tab appeared, along with 2 new tabs I had opened before the update.  But everything in the "Restore previous session" tab was blank, so my now previous-to-last session disappeared. Gone. 

There is something missing in the "Restart to update". If I had simply killed the Firefox process, and reopened it, it would've been fine. (This is likely the same thing that causes me to never close Firefox, but always kill it.)


Expected results:

The "Restore previous session" tab should still have contained my previous-to-last session, as it would have if I had manually killed Firefox, and restarted it.
Bug: page context menu appear too SLOW when have many containers
Status: UNCONFIRMED
Priority: --
Created: 2025-02-10 08:06:48+00:00
Resolved: 2025-02-26 20:46:11+00:00

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

Steps to reproduce:

1. In a clean profile, let's create 10k containers:

```js
for (let index = 0; index < 10000; index++) {
	browser.contextualIdentities.create({
		name: `debug-${index}`,
		icon: "circle",
		color: "toolbar",
	});
}
```
2. Right-click on the link on any page to pop up the context menu
3. Move and hover the pointer to the "Open Link in New Container Tab" item




Actual results:

Before above "step 3" occurs, any link or non-link call out the context menu, it immediately displays without any problems.

But once "step 3" is done once. Calling out the context menu anywhere on the page will be very slow.

Even if the context menu is called out on non-links, that is, the menu will not contain "Open Link in New Container Tab" item.

Note that its disappearance has also slowed down. 
So, the whole interaction with the context menu will be very hysteresis and slow.

Attachment recording will show you these all very well.

Unless the browser is closed and restarted, there seems to be no way to get it back to normal.


Expected results:

After rendering the "Open Link in New Container Tab" item once, it should not cause any subsequent context menu interaction to become slow.

Extremely large numbers of containers are possible, such as the use case of "one-time containers".

Current ways to avoid this issue:
- After opening the browser, absolutely avoid hover the pointer on "Open Link in New Container Tab" item, avoiding its first rendering. (It's hard to do in actual daily use)
- Hide "Open Link in New Container Tab" item in context menu through `chrome.css` (It's very hacky and not easy to do)
Bug: file upload windows is closed
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2025-02-10 09:44:04+00:00
Resolved: 2025-03-03 11:58:21+00:00

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

Steps to reproduce:

After Firefox was updated, strange problems started to occur
A file upload window opens on sites such as business suite (facebook), X (studio), Instagram. It does not return to the same tab after selecting the file. Firefox tab is not displayed. The previous application from the open windows applications opens. Firefox does not close completely, but it is ridiculous that it returns to the previous application. I have to open Firefox again with ALT+TAB every time.
Another problem is that pirha.org site is displayed properly in Chrome but not in Firefox.
There is an unnecessary space between the site header and body. The last link in the site navigation appears a little higher.
These situations occurred after the Firefox update.
I hope Firefox fixes these problems, good work
Bug: Following “Science” and “Parenting” topics other two sections appear into “Followed Topics” list even if they haven’t been actually followed
Status: NEW
Priority: --
Created: 2025-02-10 12:53:22+00:00
Resolved: 2025-02-11 15:24:16+00:00

**[Notes]:**
- This issue is also reproducible following “Parenting” when "Life Hacks” topic is followed, too.
- This issue is reproducible also for blocking action for the same two sections: “Science” and “Parenting”.
- This issue is not reproducible for the other topics.

**[Affected versions]:**
- Firefox Beta 136.0b3 - Build ID: 20250207091649


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


**[Prerequisites]:**
- Have the Firefox Beta 136.0.3 build en* locale installed.
- Have the following prefs set to "true" on the "about:config" page:
  - browser.newtabpage.activity-stream.discoverystream.sections.personalization.enabled
  - browser.newtabpage.activity-stream.discoverystream.sections.enabled
  - browser.newtabpage.activity-stream.discoverystream.sections.customizeMenuPanel.enabled
  - browser.newtabpage.activity-stream.discoverystream.sections.cards.enabled
- Have the "browser.search.region" pref set to US.


**[Steps to reproduce]:**
1. Open the browser from the prerequisites.
2. Open a new tab.
3. Click on the “Follow” button from the “Science” section.
4. Click on the gear icon from the right bottom of the page.
5. Click on the "Followed and blocked topics" button under the "Sponsored stories" checkbox.
6. Notice the "Followed Topics" section.

**[Expected result]:**
- Following the “Science” topic no other section appears in the “Followed Topics” list.

**[Actual result]:**
- Following the “Science” section, “Education” topic appears also in the “Followed Topics” list even if it hasn’t been actually followed.

**[Additional Notes]:**
- A video of this issue can be find [here](https://drive.google.com/file/d/1KzSL2wuK3FwpHnybdbg6Gd5jJQltfMJa/view?usp=sharing).
- This issue is also reproducible for the rest of the locales where the topics are available.
Bug: In version 135 when a user clicks on a Telerik RadButton in a Telerik RadWindow modal popup in our web application the tab crashes.
Status: UNCONFIRMED
Priority: --
Created: 2025-02-10 13:52:38+00:00
Resolved: 2025-03-03 12:21:02+00:00

Steps to reproduce:

I opened the RadWindow and clicked on a RadButton.


Actual results:

The tab crashed and showed a dialog titled, "Gah. Your tab just crashed."


Expected results:

The .Net postback event should have fired to handle the click event on the server.  I know that it didn't because I had a break point set in the server side code which was not reached.
Bug: Update targeting for Desktop to Mobile Adoption message
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2025-02-10 14:38:38+00:00
Resolved: 2025-02-11 09:58:07+00:00

We'd like to rollback the current targeting for the Desktop to Mobile Adoption message and add `!(sync || {}).mobileDevices` to prevent the message from being shown to users that already have a mobile device connected.
Bug: The “Followed and Blocked topics” panel content overlaps the “Personalize new tab” panel content on browser vertical resize
Status: NEW
Priority: --
Created: 2025-02-10 15:06:13+00:00
Resolved: 2025-02-10 15:06:13+00:00

**[Affected versions]:**
- Firefox Beta 136.0b3 - Build ID: 20250207091649

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

**[Prerequisites]:**
- Have a Firefox Beta 136.0b3 build with en-US locale installed.
- Have the following prefs set to "true" on the "about:config" page:
         - browser.newtabpage.activity-stream.discoverystream.sections.personalization.enabled
         - browser.newtabpage.activity-stream.discoverystream.sections.enabled
         - browser.newtabpage.activity-stream.discoverystream.sections.customizeMenuPanel.enabled
         - browser.newtabpage.activity-stream.discoverystream.sections.cards.enabled
- Have the "browser.search.region" pref set to "US".

**[Steps to reproduce]:**
1. Open the browser using the profile from the prerequisites.
2. Open a new tab.
3. Resize the browser window to its maximum height/width.
4. Click on the gear icon from the right bottom of the page.
5. Click on the "Followed and blocked topics" button under the "Sponsored stories" checkbox.
6. Resize the window vertically to half height.
7. Focus the "Followed and blocked topics" panel and scroll down using the mouse/keyboard.
8. Observe the panel’s content.


**[Expected result]:**
- The content of the "Followed and blocked topics" is displayed when scrolling down.

**[Actual result]:**
- The content of the "Personalize new tab" panel is displayed in an overlapping manner with the "Followed and blocked topics" panel when scrolling down.

**[Notes]:**
- This issue is reproducible on different vertical sizes of the browser.
- This issue is NOT reproducible on horizontal resize of the browser.
- This issue is also reproducible for the rest of the locales where the topics are available.
- Attached a screen recording of the issue [here](https://drive.google.com/file/d/1ltP2o1vQ0eiwNUoZdEelP0qW7C9udamm/view?usp=sharing).
Bug: Newtab showWeather has Nimbus setup prefs mismatch
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2025-02-10 15:24:57+00:00
Resolved: 2025-02-18 11:00:47+00:00

showWeather is using Services.prefs.getStringPref to get the setup prefs, but the Nimbus feature manifest is using fallbackPref.

This was regressed in bug 1924597. Before that bug, it was using fallbackPref and NimbusFeatures.pocketNewtab.getVariable.

It should have been moved to setPref and Services.prefs.getStringPref, but the feature manifest never got the change for using setPref, and is still using fallbackPref.
Bug: Tab groups from private windows appear in "Add tab to group" menu in non-private windows and vice-versa
Status: RESOLVED
Priority: P1
Resolution: DUPLICATE
Created: 2025-02-10 15:57:20+00:00
Resolved: 2025-02-14 04:41:47+00:00

STR:
1. Open two windows, one private and one non-private.
2. In the non-private window, open some tabs and create a tab group.
3. In the private window, right click a tab. Hover over the "Add Tab to Group" context menu item.

Expected result:
- The tab group from the non-private window does not appear.

Actual result:
- The tab group from the private window appears.

Notes:
The reverse of this is also true, i.e. tab groups from private windows appear in context menus for non-private windows.
Bug: Shortcut title overflowing in Edit/New Shortcut dialogs from about:home
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2025-02-10 16:36:09+00:00
Resolved: 2025-02-18 06:15:31+00:00

**Found in**
* 136.0b3

**Affected versions**
* 137.0a1 
* 136.0b3
* 135.0

**Tested platforms**
* Affected platforms: Windows 11, macOS 14, Ubuntu 22.04
* Unaffected platforms: none

**Steps to reproduce**
1. Navigate to about:home and add a new shortcut or edit an existing one by opening the 3-dot menu from any shortcut
2. In the New/Edit Shortcut dialog, enter a long title in the “Title” field (e.g. TestTestTestTestTestTestTestTestTestTestTest)
3. Observe how the title is displayed under the shortcut image

**Expected result**
* The title is truncated and there are no overflow issues

**Actual result**
* The title is not truncated. If the entered text contains no spaces, it extends across horizontally. If the text contains spaces, it wraps onto multiple lines, causing the dialog height to increase

**Regression range**
* Last good build: 2024-12-05
* First bad build: 2024-12-06
* Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=25396aa6b22994d5ce0ba4b961bbf64797d57193&tochange=0030e1c01a2f651cb086e573814f67729598eec9 
* Potentially regressed by: 1433530

**Additional notes**
* See the attached screenshot
Bug: UserUnit isn't taken into account when rendering the text layer
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2025-02-10 17:44:57+00:00
Resolved: 2025-02-27 13:25:09+00:00

Attach (recommended) or Link to PDF file here:

Steps to reproduce the problem:
1. Open the pdf
2. Try to select the text

Thanks to mozregression, the regressor is bug 1939257 and very likely because of:
https://github.com/mozilla/pdf.js/pull/19196

:Snuffleupagus would mind to have a look please ?
Bug: Resolve glitchy animations with expand on hover with the new sidebar
Status: ASSIGNED
Priority: P1
Created: 2025-02-10 18:13:33+00:00
Resolved: 2025-02-19 19:25:38+00:00

There's a glitchy-ness when hovering right on the edge of the launcher as the mouseover / mouseout event listeners keep getting called in a loop until you move the mouse. We may just want to debounce the event listeners.
Bug: Nightly didn't attempt to load URL in address bar
Status: NEW
Priority: --
Created: 2025-02-10 18:15:28+00:00
Resolved: 2025-02-25 21:37:10+00:00

I believe I may have encountered a race condition that broke a tab in my Nightly. I closed a tab, then clicked a link from another application in quick succession, and the link from the other application opened a tab, but Nightly never made an attempt to load the URL. I tried clicking in the address bar and pressing the return key, clicking the "Go" button, as well as choosing the URL from the address bar popout menu. None of these actions caused Nightly to change state.

Here is a profile of me attempting the above actions to get the URL to load: https://share.firefox.dev/42LFD0F

Afterwards I was able to close the tab, click the link again, and this time it opened properly.
Bug: When enabling Vertical tabs in about:preferences, the sidebar launcher should be expanded by default
Status: RESOLVED
Priority: P1
Resolution: DUPLICATE
Created: 2025-02-10 18:18:47+00:00
Resolved: 2025-02-11 13:44:50+00:00

With a new profile, if you navigate to about:preferences and enable Vertical Tabs, the sidebar launcher is collapsed when it should be expanded by default. If you then toggle off Vertical Tabs and then re-enable it, you'll see that it _does_ expand the sidebar launcher by default as expected. So it seems this is only an issue when initially toggled.

STR:
With a clean profile, navigate to about:preferences
Find the sidebar / vertical tabs settings
Check the Vertical tabs options
Notice the sidebar launcher area is collapsed rather than expanded