av9ash/GitBugs huggingface dataset:
Bug: DataTables warning: table id=logTable - i18n file loading error – ClearURLs extension adverse effect on GitHub can not be debugged
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2025-01-26 14:52:57+00:00
Resolved: 2025-01-26 16:39:38+00:00

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

Steps to reproduce:


1. copy the following URL to the clipboard
2. https://github.com/freebsd/freebsd-src/pulls?q=is:pr%20sort:updated-desc
3. visit <https://addons.mozilla.org/addon/clearurls/>
4. add the recommended extension to Firefox
5. Control-T
6. Control-V, then Return or Enter
7. copy the following string to the clipboard
8. author:grahamperrin iwlwifi
9. in the GitHub tab, click in the filters field
10. Control-V, then Return or Enter
11. click the listing for 'iwlwifi.4: bugs: tracking and clarification'



Actual results:


After step 10, peculiar flickering of the 'author:grahamperrin iwlwifi' tail end of URL in the address bar of Firefox.

After step 11, the required page does load **however** the URL and title bar are wrong.


Expected results:

After step 10, the URL should be: 

<https://github.com/freebsd/freebsd-src/pulls?q=is%3Apr+sort%3Aupdated-desc+author%3Agrahamperrin+iwlwifi>

After step 8, the URL should be: 

<https://github.com/freebsd/freebsd-src/pull/1541>
Bug: Trying to open a recently closed tab results in the wrong tab opening
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2025-01-26 16:06:14+00:00
Resolved: 2025-02-13 13:26:53+00:00

Steps to reproduce:

This isn't the only way to reproduce it and I haven't tested if re-opening closed windows is affected as well.

1. Open two windows.
2. On window A, open three links and a newtab.
3. On window A, right-click on the newtab and close the other tabs.
4. On window B, go to the hamburger menu > History > Recently closed tabs and select the first entry.
5. On window B, open a new tab, and close the tab opened at the previous step.
6. On window B, go again to the recently closed tabs and select the second entry.


Actual results:

The tab that reopens at step 6 is not the one clicked on the menu.

At some point I encountered an entry in the recently closed tabs menu that didn't open any tab at all when clicked, but I don't have STR for that.


Expected results:

Regressed by Bug 1932941.
Bug: Mouse-over title overflow on about:home issue with non-Roman text
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2025-01-26 16:13:16+00:00
Resolved: 2025-01-30 21:10:34+00:00

The mouse-over on some items causes the shifting of the `about:home` rows . 
The issue appears to me to be the line-height with non-Roman (non-left-to-right) text, causing too much space between the first and second line.

The issue is with `<span class="title-label" dir="auto">`

```css
.top-sites-list .top-site-outer:hover .title:not(.sponsored) .title-label, .top-sites-list .top-site-outer:focus-within .title:not(.sponsored) .title-label {
  -webkit-line-clamp: 2;
  white-space: wrap;
  word-break: break-all;
}
```


_Nightly, Ubuntu 24.04 Wayland_
Bug: Pinned Tabs scrambled after browser restart
Status: NEW
Priority: P3
Created: 2025-01-27 01:00:42+00:00
Resolved: 2025-02-20 10:14:24+00:00

I exited Firefox normally in response to an update notification and ended up with 135.0b6. Upon starting Firefox back up with the new version, all my pinned tabs had been rearranged into a seemingly random order. My main window has 12 pinned tabs so bringing them back into the previous order was a little annoying. It seems like my non-pinned tabs weren't scrambled, though - all my tabs in all my windows seem to be in their proper order, it just scrambled the pinned ones.

I have Tree Style Tabs active if that matters.
Bug: When viewing NFL score, clicking the "Trending" tab, scrolling through tweets, and then refreshing the page, the search query removes the last character from the original query (ex. "NFL" --> "NF").)
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2025-01-27 02:14:25+00:00
Resolved: 2025-02-11 09:33:46+00:00

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

Steps to reproduce:

Searched "NFL", clicked on the live game tracker for the Buffalo Bills vs. Kansas City Chiefs game, clicked on "Trending" tab, scrolled through displayed tweets, then reloaded the page.


Actual results:

Upon manual reload, search query changed from "NFL" to "NF". Upon immediate second manual reload, search query changed from "NF" to "N". This behavior also occurred for query "bills vs chiefs" --> "bills vs chief" --> ... --> "<empty query>".


Expected results:

Upon manual reload, search query should have stayed the same, going from "NFL" to "NFL".
Bug: Pinning first tab should ungroup it
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2025-01-27 05:05:39+00:00
Resolved: 2025-02-03 10:23:54+00:00

When you have a tab group and pin one of its tabs, behavior is a bit erratic:

 * The first pinned tab seems to work (see attached screenshot).
 * But as soon as you pin another tab from another group, then that tab gets detached from its group.
 * If you add many tabs, so that the tab list scrolls, then the pinned tab gets completely inaccessible.

I'd expect either:

 * Pinning a tab always "ungroups" it. A bit unfortunate since it might be useful to have a tab group in the pinned tab area, but maybe ok.
 * Pinning a tab pins the whole group.

But I haven't thought too hard about this. In any case making the tab inaccessible seems clearly a bug.
Bug: Tab overflow menu does not reflect the current state of saved tab groups reopened or deleted from the overflow menu until reopened
Status: RESOLVED
Priority: P2
Resolution: DUPLICATE
Created: 2025-01-27 06:37:12+00:00
Resolved: 2025-01-30 13:10:31+00:00

### Steps to reproduce

1. Create a new tab group with tabs.
2. Right click on the tab group name and select "Save and close group".
3. Open the tab overflow menu.
4. Right click on the saved tab group in the overflow menu.
5. Select "Open Group in This Window" or "Delete Group".

### Expected behavior

The tab group name should, depending on which comment you selected in step 5 above, either:

1. Move from the overflow menu's tab groups section to the open tabs section.
2. Or disappear from the overflow menu.

### Actual behavior

The tab group name is still listed the overflow menu's tab group even though it has been reopened or deleted. If you close and then reopen the overflow menu, the menu will then show the correct tab group state.
Bug: Right click menu doesn't highlight item under cursor
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-01-27 07:26:19+00:00
Resolved: 2025-01-27 13:50:22+00:00

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36 Edg/125.0.0.0

Steps to reproduce:

Right click in Firefox and hover over then item with the mouse cursor


Actual results:

The right click menu item under the cursor doesn't get highlighted, clicking the item still preforms the action


Expected results:

The item is highlighted
Bug: Website viewport changes when bookmark toolbar set to only show on new tab
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2025-01-27 07:48:18+00:00
Resolved: 2025-01-31 10:46:26+00:00

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

Steps to reproduce:

Whenever i switch between new tab and a website tab, the website's screen or viewport changes especially the footer, it feels like after switching to the new tab the bookmark bar gets visible in every tab and therefore after switching to the website tab the bar gets hidden and it causes the issue.
Bug: The vertical tab bar does not automatically expand when the bookmarks/history sidebar is closed.
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2025-01-27 10:29:26+00:00
Resolved: 2025-02-05 10:57:10+00:00

STR:
1. Enable `Vertical tabs` from about:preferences#experimental
2. Expand the vertical tabs bar
3. Open History Sidebar (Ctrl+H)
4. Open Bookmarks Sidebar (Ctrl+B)
5. Close Bookmarks Sidebar (Ctrl+B)

Actual Results:
The vertical tabs bar remains collapsed.

Expected Results:
The (expand/collapse) vertical tab bar should return to the state it was in before the sidebar was opened.
In this case, the vertical tab bar should return to the state of step 2 (i.e., expanded).
Bug: Upon closing firefox, while having the option enabled to confirm before closing multiple tabs, pinned tabs are being ignored, i.e. for one unpinned tab, firefox will always close without asking for confirmation, even if multiple pinned tabs are open.
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-01-27 11:19:39+00:00
Resolved: 2025-02-04 17:37:52+00:00

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

Steps to reproduce:

1. Enable "Confirm before closing multiple tabs"
2. Have 2 pinned tabs open, and have 1 unpinned tab open
3. Close firefox


Actual results:

Firefox closes without asking for confirmation.


Expected results:

Firefox should ask for confirmation, because you have multiple tabs open.
Bug: The fade is visible when widget.macos.titlebar-blend-mode.behind-window is enabled on macOS.
Status: NEW
Priority: P2
Created: 2025-01-27 11:19:51+00:00
Resolved: 2025-02-25 22:02:27+00:00

The fade is visible when widget.macos.titlebar-blend-mode.behind-window is enabled on macOS.
Bug: Firefox View appears as "Switch to Tab" suggestion, should probably be a secondary action instead
Status: NEW
Priority: P3
Created: 2025-01-27 11:46:44+00:00
Resolved: 2025-02-17 16:17:55+00:00

Steps to reproduce:

* Open Firefox View
* Click another tab and type `firefox` into the address bar


Actual results:

Your address bar suggestions now include `about:firefoxview [Switch to Tab]`.


Expected results:

Firefox View isn't treated as a tab by the GUI and can't be closed, so it shouldn't be shown as a "Switch to Tab" suggestion.
Bug: When moving multiple tabs to the end, if the last item is an open tab group, moved items are added to the group
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2025-01-27 14:21:15+00:00
Resolved: 2025-03-05 07:06:25+00:00

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

Steps to reproduce:

It is important that the last item in a window should be an open tab group.

1. CMD + Click or SHIFT + CLICK on the tabs to select multiple tabs.
2. Right click and select “Move Tabs > Move to End”.



Actual results:

The selected tabs are added to the open group at the end.


Expected results:

The tabs should have moved to the end ungrouped, after the open group.
Bug: First key typed is ignored after entering search mode through the contextual search secondary action using tab key
Status: NEW
Priority: P3
Created: 2025-01-27 15:38:28+00:00
Resolved: 2025-01-27 20:10:36+00:00

**Found in**
- Nightly Version 136.0a1

**Steps to reproduce**
1. Navigate to a page of an engine not set to default, for example https://www.wikipedia.org/
2. Type a character into the address bar such that the top/auto-completed result is a URL from history
3. Press the tab key to enter search mode via the contextual search secondary action
4. Type in any additional character to continue your search string

**Expected result**
- Additional key typed is registered and added to search query string

**Actual result**
- First additional key typed is not registered
Bug: Intermittent [tier 2] browser/components/sessionstore/test/browser_restore_verticalPinnedTabs.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2025-01-27 16:43:52+00:00
Resolved: 2025-02-24 12:05:19+00:00

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

---
```
[task 2025-01-27T15:37:41.655Z] 15:37:41     INFO - TEST-PASS | browser/components/sessionstore/test/browser_restore_verticalPinnedTabs.js | Third tab is selected - 
[task 2025-01-27T15:37:41.656Z] 15:37:41     INFO - Buffered messages finished
[task 2025-01-27T15:37:41.658Z] 15:37:41     INFO - TEST-UNEXPECTED-FAIL | browser/components/sessionstore/test/browser_restore_verticalPinnedTabs.js | First tab has matching URL - Got "about:blank", expected "https://www.example.com/"
[task 2025-01-27T15:37:41.658Z] 15:37:41     INFO - Stack trace:
[task 2025-01-27T15:37:41.658Z] 15:37:41     INFO - chrome://mochikit/content/browser-test.js:test_is:1627
[task 2025-01-27T15:37:41.658Z] 15:37:41     INFO - chrome://mochitests/content/browser/browser/components/sessionstore/test/browser_restore_verticalPinnedTabs.js:test_pinned_tabs_restored_position:89
[task 2025-01-27T15:37:41.658Z] 15:37:41     INFO - chrome://mochikit/content/browser-test.js:handleTask:1147
[task 2025-01-27T15:37:41.658Z] 15:37:41     INFO - chrome://mochikit/content/browser-test.js:_runTaskBasedTest:1219
[task 2025-01-27T15:37:41.658Z] 15:37:41     INFO - chrome://mochikit/content/browser-test.js:Tester_execTest:1360
[task 2025-01-27T15:37:41.658Z] 15:37:41     INFO - chrome://mochikit/content/browser-test.js:nextTest/<:1136
[task 2025-01-27T15:37:41.658Z] 15:37:41     INFO - chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:SimpleTest.waitForFocus/<:1058
[task 2025-01-27T15:37:41.659Z] 15:37:41     INFO - TEST-PASS | browser/components/sessionstore/test/browser_restore_verticalPinnedTabs.js | Second tab has matching URL - 
```
Bug: Hovering over items in menus doesn't show them as hovered on wayland
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2025-01-27 17:00:36+00:00
Resolved: 2025-01-29 11:56:44+00:00

This happens on nightly but not on stable.

To reproduce, just right click on a page to open the context menu and hover over anything. The same thing happens with any other menu. I attached a video to show it off. 
Note that while I can click things in the right click menu, the top right menu doesn't work at all 

Nightly version: 136.0a1 (2025-01-27)

I tested this on both sway and weston, with clean profiles.
Running with `WAYLAND_DISPLAY= firefox` to force it to use XWayland "fixes" the problem.

EDIT: Tested with 135.0b9 and it works properly there
Bug: [Android] Heuristic for identifying language models downloaded on the fly has regressed
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2025-01-27 18:20:09+00:00
Resolved: 2025-01-27 18:37:03+00:00

## Steps to reproduce
On an Android device: 
* Delete or else ensure no languages are downloaded (Browser Menu -> Settings -> Translations -> Download Languages)
* Perform a translation on a language that is not downloaded / has not been translated before 
* Open the downloaded language list again (Browser Menu -> Settings -> Translations -> Download Languages)
* Notice the language isn't in the list -> as of Bug 1940544
* Perform a manual download on any language or hard close and reopen the app, notice the expected languages will **not** sync back in (divergence from bug 1940544) 

## Previous behavior

Downloaded language list should count models downloaded on the fly during a translation.

## Workaround behavior

Performing a two way translation will sync the model to the list. For example, translate English -> French and then French -> English.

## Additional notes:
I'm fairly confident the prior behavior only required a one way translation to appear as "downloaded" since when a model is downloaded the idea is the download will be going to the target language. (I could be misremembering the prior behavior; however, bug 1940544 makes me inclined to think that I'm not. I'll try to find if these behavior was ever documented in a comment somewhere.)

Occurring on release 134, but there is some oddness because I reported bug 1940544 only 19 days ago. Could a reformatting of remote settings broke an `isDownloaded` heuristic?

Would be related to the `hasAllFilesForLanguage`. GeckoView calls from [here](https://searchfox.org/mozilla-central/rev/a965e3c683ecc035dee1de72bd33a8d91b1203ed/mobile/shared/modules/geckoview/GeckoViewTranslations.sys.mjs#317).
Bug: Firefox's "List all tabs" menu janks for a long time if you have hundreds of tabs open with large-filesize favicons (e.g. bugzilla)
Status: NEW
Priority: --
Created: 2025-01-27 19:18:29+00:00
Resolved: 2025-02-12 12:11:55+00:00

tl;dr the "List all tabs" menu can be super-expensive to open.  (I noticed this because we're showing a tab-groups onboarding pop-up, which points users to the "List all tabs" menu as part of its instructions; I tried the list-all-tabs menu and was surprised at how slow it was to open in my regular browsing profile.)

The real-world STR are to open the "list all tabs" menu in a Firefox window where you have hundreds of bugzilla tabs, by e.g. following instructions in bug 1867161 comment 0.   But probably don't **actually** do that because generating such a window may send a ton of traffic to Bugzilla all at once, which isn't nice to the Bugzilla servers.  So I'm providing friendlier STR, using  a local web server with an extra-expensive bugzilla favicon, based on bug 1867161 comment 3.

STR:
1. Follow steps 1-4 of bug 1867161 comment 3 (to open a window with 500 tabs that are using an extra-heavyweight version of the Bugzilla favicon.
Note: this occasionally fails to get me a window with 500 tabs - I sometimes just saw 2 tabs of Firefox's firstrun pages instead -- but if that happens, you can still get a window with 500 tabs by doing Ctrl+N, or quitting & restarting Firefox with that same profile.)

2. Click the "List all tabs" menu dropdown-arrow at the right end of your tabstrip.

ACTUAL RESULTS:
Seconds-long jank before the menu opens.

EXPECTED RESULTS:
No such jank.
Bug: Onboarding message about "if you close a tab group" is unclear about what it means by "close"
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2025-01-27 20:28:57+00:00
Resolved: 2025-02-24 18:52:12+00:00

I noticed a tab-groups-onboarding message today which pointed to the "List all tabs" menu.  The text said:
```
If you close a tab group, you can reopen it here anytime.
```
(This was added in bug 1943442.)

We might want to modify the language there -- I think we might really intend to say "collapse" or something on those lines, rather than "close"?

Intuitively, I interpret (and I think users interpret) "close a tab group" as meaning "close all of the tabs in the tab group" (which for a tab group would mean clicking all the "x" buttons, or right-clicking the tab-group and choosing "Delete").  And if you do either of those things, then the list-all-tabs menu **does not** have any UI to reopen that group, which seems to superficially contradict what this onboarding message was trying to say.
Bug: All the "New Tab" features should be disabled when the "New Tab Page" is disabled ("browser.newtabpage.enabled"=false)
Status: NEW
Priority: --
Created: 2025-01-27 21:31:43+00:00
Resolved: 2025-02-14 12:09:11+00:00

I’ve noticed a recurring issue in our WebDriver implementation, which intentionally disables `about:newtab`. Each time a new feature is added to the New Tab page — such as wallpapers, the activity stream content, or other enhancements — a number of new preferences are introduced. This requires us to manually identify and disable each feature individually to ensure it doesn’t interfere with our automation scenarios, and that even with `about:newtab` disabled.

To prevent this extra work in the future, we suggest that any new feature on the New Tab page should only be enabled if the `browser.newtabpage.enabled` preference is set to true. This would act as a single, overarching check to ensure features dependent on the New Tab page remain inactive when the page itself is disabled.

This adjustment would significantly streamline automation workflows by reducing the need for repeated manual intervention whenever new features are added. It would also ensure consistency across testing environments and avoid potential disruptions caused by inadvertently enabled features.
Bug: Mozilla Accounts cannot finish sync
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2025-01-27 21:35:30+00:00
Resolved: 2025-02-11 21:17:40+00:00

Starting Jan 23, Firefox iOS sync integration tests fail because the sync "never" finishes even after providing valid user name and password. Note that the sync integration tests the stage server.

*Steps*
1. Create a new Mozilla account.
2. (Use TPS to sync tabs, bookmarks etc to the account.)
3. Open Firefox iOS.
4. Sign in to the Mozilla account using the credentials from step 1.
5. Open Settings screen.
6. Wait for "Syncing..." to finish.

*Expected*
Sync eventually finishes (in under 45 sec).

*Actual*
Sync seemingly never finishes. I tried to navigate away from the settings screen when the sync was in progress and could not see the items (bookmarks, tabs etc) synced to the device.

Video (from step 3 and after):
https://photos.app.goo.gl/HH3wMFQ7erNbbFHv7
Bug: Some favicons are very jagged in Firefox vs other browsers
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-01-28 03:09:10+00:00
Resolved: 2025-02-04 15:40:41+00:00

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

Steps to reproduce:

Go to https://carusosignature.com/ or another affected site.


Actual results:

Some favicons, like Google's, is nice and antialiased.  Some, like Discord and Microsoft Teams, seems be be lacking in antialiasing, but generally looks fine.  (Might be because of the sites dynamically drawing their icons based on read/unread messages).  However, the Caruso Signature favicon looks extremely jagged.  I remember coming across other website that seemed similarly affected, but don't remember which sites.


Expected results:

The icon should look like it does in e.g. Chrome (see attachment for comparison).
Bug: [Sections Experiment] UI regression: excerpt on cards is not limited by number of lines
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2025-01-28 03:41:08+00:00
Resolved: 2025-01-30 04:10:57+00:00

Scott has noticed the length of the excerpt has regressed following the merge of https://phabricator.services.mozilla.com/D234142. It should be three lines for medium cards and four lines for large cards.
Bug: xss vulnerability
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2025-01-28 05:53:44+00:00
Resolved: 2025-01-28 06:42:11+00:00

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

Steps to reproduce:

dfgfddh


Actual results:

fgfd


Expected results:

fdgfdg
Bug: Account profile toolbar icon flickers when syncing is in progress
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2025-01-28 08:42:49+00:00
Resolved: 2025-01-30 19:55:52+00:00

**Affected FxA versions:**

- 1.302.1;

**Prerequisites:**

- Have an Fx account created and be connected to Sync;

**Steps to reproduce:**

1. Hit the “Sync now” option from the Firefox account toolbar option;
2. Observe the avatar from the toolbar option;

**Expected result:**

- The avatar is not flickering;

**Actual result:**

- The avatar is flickering;

**Additional notes:**

- See attached media;