av9ash/GitBugs huggingface dataset:
Bug: color of the unicode characters that are defined in a color impossible to style with css
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2025-02-28 11:31:04+00:00
Resolved: 2025-02-28 11:35:49+00:00

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

Steps to reproduce:

go to https://ewnjtgouierg.github.io/ffbugs/BlueUnicode.html


Actual results:

color of the anchor character should be black


Expected results:

it is blue

in Chromium it is black

As i understand Unicode character color is only recommended one and whether to use it or not depends on the software and the media it works with.

Browser's medium (HTML) features a separate mechanism (CSS) for a full control over the color - to choose any one available on the hardware, and taking this feature away by hardcoding the recommended color doesn't make sense.

I understand it's a complex topic, but given that there seem to be no bugs about it yet - at least not among recommended ones when trying to add a bug "unicode characters color" - adding it.
Bug: Add Tabs to Group should show all Groups for the selection of tabs that also has at least one free tab selected
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2025-02-28 11:38:37+00:00
Resolved: 2025-03-05 11:06:12+00:00

**Found in**
* 137.0a1 (2025-02-28)

**Affected versions**
* 137.0a1 (2025-02-28)

**Affected platforms**
* all

**Steps to reproduce**
1. Have 2 Tab groups with 4 tabs each.
2. Select 3 Tabs from the Second group as well as a free tab.
3. Right click the selected Tabs and Open the Add Tabs to group submenu.

**Expected result**
* Both Tab groups should be displayed since there is a free tab with the rest of the selected tabs.
Adding the selected Tabs to the group that already has a few of those tabs should only add the free tab.

**Actual result**
* If there is a single Tab already inside the Group, the Tab group is not displayed in the Add Tabs to group submenu.

**Regression range**
Not a regression.
Bug: Firefox crashes on Agent timeout when  TimeoutResult is set to 1
Status: NEW
Priority: --
Created: 2025-02-28 12:19:50+00:00
Resolved: 2025-03-05 23:15:16+00:00

**Found in**
* 137.0a1 (20250227215252)



**Affected versions**
* 137.0a1 (20250227215252) 








**Tested platforms**
* Affected platforms:  Windows 10x64, 
* Unaffected platforms: Ubuntu 24, macOS


**Preconditions**
* Download the DLP test assets from https://drive.google.com/file/d/1yjqVRuxdKV3WnO7D2wzMgDXBuYBxUgVw/view
* Create a distribution folder inside the Firefox folder and paste the policies-4.json to it and then rename it to policies.json
* set "TimeoutResult": 1 in policies.json file
* DLP Agent is running: `.\content_analysis_sdk_agent.exe --user --toblock=.*\d{3}-?\d{2}-?\d{4}.* --towarn=.*warn.* --delays=10`

**Steps to reproduce**
1. Open Firefox and perform clipboard paste.



****Expected result****
* No crash.

**Actual result**
* Firefox crashes.


**Regression range**
*  pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a7b709e4e4fa320e15ae82f8a0b7b1a43dadd6d5&tochange=d0efb392c1783f46f27a946f48e3ef729ecd3675 . I don’t know if bug 1950256 or bug 1919703 is the regressor. I will ni? David.

**Additional notes**
* Attached a screen recording.
* Marking this as high-impact  ([fidefe-quality-foundation?]) since this is a recent regression and a crash.
Bug: Firefox 135.0.1 just updated.  Tabs not working as before. Restore history not working as before
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-02-28 15:44:24+00:00
Resolved: 2025-03-04 15:35:46+00:00

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

Steps to reproduce:

I did a Software update for my MacBook Air, now OS 15.3.1
Prior to that, in Firefox browser I had opened about a dozen tabs, reading the news.


Actual results:

Upon restart, my Firefox browser, now 135.1, only offers three tabs.  I went to History and Restore isn't there anymore.  I would like to restore the 12 tabs.  I see the workaround, just one by one reopening what's in recent history.  But even when I do that, the Tabs bar doesn't collect the tabs the way it used to.  It seems to only allow three tabs.  Not sure about that, now it has several Mozilla related tabs, total of 5 tabs right now.


Expected results:

Restore History should have opened the numerous articles I was planning to read.
Not sure I understand 'user agent string'
Bug: Firefox logo uses White on Yellow when some themes are installed
Status: NEW
Priority: --
Created: 2025-02-28 16:45:31+00:00
Resolved: 2025-03-05 11:34:32+00:00

Steps to reproduce:

Fresh Firefox Nightly profile
Install https://addons.mozilla.org/en-GB/firefox/addon/expressionist-balanced/?utm_source=addons.mozilla.org&utm_medium=referral&utm_content=search



Actual results:

Note how the Firefox logo and some other content on the new tab page is White on Yellow background, and is therefore not very visible


Expected results:

Should be Black on Yellow
Bug: Unreadable text contrast on Firefox new-tab page (dark-on-dark or light-on-light), if preferred color-scheme differs from Firefox theme
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2025-03-01 06:19:02+00:00
Resolved: 2025-03-05 05:59:45+00:00

I don't have STR yet, but tl;dr Firefox Nightly on one of my machines has black-text-on-black-background on its new-tab page. See attached screenshot.

I'll post STR shortly once I've got all the variables.  So far I was able to bisect with mozregression to get regression range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e01905dbeca47f0983b9a11f35eb191630814000&tochange=6a49f8a0511a25692e9473c6313f7f7a19a2a413

...which is bug 1950576.

[Tracking Requested - why for this release]: prominent readability regression on new-tab page.
Bug: Restoring tabs from history does not restore tab groups
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-03-01 13:43:22+00:00
Resolved: 2025-03-03 16:35: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:

1. Enable browser.tabs.groups.enabled
2. Close Firefox
3. Restart Firefox
4. History > Manage history > Today > Open in all tabs


Actual results:

All tabs are restored, but all my created tab groups are lost


Expected results:

I need all tab groups to successfully be restored.
Bug: contentanalysis-timeout-block-error-message-content is wrong
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2025-03-01 17:12:51+00:00
Resolved: 2025-03-04 05:06:18+00:00

Localization noticed a string mistake.  Currently:

```
contentanalysis-timeout-block-error-message-content = The connection to { $agent } connection timed out. { $contentName } has been blocked.
```

Note the double connection.
Bug: Firefox cannot handle ChatGPT. Causes slowdowns on all PCs.
Status: UNCONFIRMED
Priority: --
Created: 2025-03-02 02:42:04+00:00
Resolved: 2025-03-02 15:51:36+00:00

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

Steps to reproduce:

Navigate to https://chatgpt.com/?oai-dm=1
Add a reply to existing chat or start a new one.
Hit enter to submit.


Actual results:

ChatGPT takes anywhere from 5 minutes to 30 minutes to generate a response. Firefox also displays "This page is slowing down Firefox" and sometimes causes Firefox to be "Not Responding".

This has been an issue for about a month and there are a couple of posts on Reddit on /r/ChatGPT about it.

Chrome generates responses in seconds

This same issue persists on five different PCs, two Windows 11 PCs and three Windows 10 PCs.


Expected results:

Firefox should not be slowed down when using ChatGPT and responses should show in seconds like in Chrome.
Bug: Address bar is transparent when pasting text into new window
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2025-03-02 10:06:28+00:00
Resolved: 2025-03-05 17:35:33+00:00

Steps to reproduce:
1) Open a new window with keyboard shortcut (Ctrl+N/Cmd+N)
2) Quickly paste text with keyboard shortcut (Ctrl+V/Cmd+V)

Actual results:
Sometimes, the address bar is transparent

Expected results:
The address bar has a background color
Bug: Intermittent browser/extensions/newtab/test/browser/abouthomecache/browser_locale_change.js | single tracking bug
Status: NEW
Priority: P5
Created: 2025-03-02 14:08:56+00:00
Resolved: 2025-03-02 14:08:56+00:00

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

---
```
[task 2025-03-02T13:07:18.353Z] 13:07:18     INFO - TEST-PASS | browser/extensions/newtab/test/browser/abouthomecache/browser_locale_change.js | Expected the right value set to browser.startup.abouthome_cache_result scalar. - 6 == 6 - 
[task 2025-03-02T13:07:18.354Z] 13:07:18     INFO - Simulating restart of the browser
[task 2025-03-02T13:07:18.354Z] 13:07:18     INFO - Intentionally skipping shutdown write
[task 2025-03-02T13:07:18.355Z] 13:07:18     INFO - Waiting for AboutHomeStartupCacheChild to uninit
[task 2025-03-02T13:07:18.355Z] 13:07:18     INFO - AboutHomeStartupCacheChild uninitted
[task 2025-03-02T13:07:18.356Z] 13:07:18     INFO - Waiting for AboutHomeStartupCache cache entry
[task 2025-03-02T13:07:18.356Z] 13:07:18     INFO - Buffered messages finished
[task 2025-03-02T13:07:18.357Z] 13:07:18     INFO - TEST-UNEXPECTED-FAIL | browser/extensions/newtab/test/browser/abouthomecache/browser_locale_change.js | Test timed out - 
[task 2025-03-02T13:07:18.357Z] 13:07:18     INFO - GECKO(5014) | Completed ShutdownLeaks collections in process 5014
[task 2025-03-02T13:07:18.357Z] 13:07:18     INFO - TEST-START | Shutdown
[task 2025-03-02T13:07:18.358Z] 13:07:18     INFO - Browser Chrome Test Summary
[task 2025-03-02T13:07:18.358Z] 13:07:18     INFO - Passed:  58
[task 2025-03-02T13:07:18.359Z] 13:07:18     INFO - Failed:  1
[task 2025-03-02T13:07:18.359Z] 13:07:18     INFO - Todo:    0
[task 2025-03-02T13:07:18.359Z] 13:07:18     INFO - Mode:    e10s
[task 2025-03-02T13:07:18.360Z] 13:07:18     INFO - *** End BrowserChrome Test Results ***
```
Bug: Lack of indication for pinned tabs in "List all tabs" meant users can accidentally close pinned tabs using the close tab button next to each tab item (when browser.tabs.tabmanager.enabled is set to true)
Status: NEW
Priority: --
Created: 2025-03-02 18:02:51+00:00
Resolved: 2025-03-04 15:34:09+00:00

Tested on 115.20.0esr, 128.7.0esr, and 135.0.1.

Prerequisites:

Pinned tabs were re-added to the "List all tabs" drop-down menu in FF92 (bug 776669), but later gated behind the `browser.tabs.tabmanager.enabled` pref in FF94 (bug 1730415). The pref was enabled by default in FF106 (bug 1786011) and then removed in FF131 (bug 1916622). Meanwhile, a `Close tab` button was added for each tab in the drop-down menu in FF115 (bug 1620199).


STR:

1. Open a bunch of new tabs and start pinning some of them.
2. Hold `Ctrl + W` to try to close all tabs. Notice how pinned tabs cannot be closed by using the keyboard shortcut.
3. Open some more new tabs.
4. Open the "List all tabs" drop-down menu.
5. Try dragging and dropping pinned tabs between unpinned tabs (and vice versa) in the drop-down menu and notice how they fail silently (this is expected behavior).
6. Start closing tabs you don't like using the close tab buttons in the drop-down menu.


Actual behavior:

Without clear indication for pinned tabs, users might mistook them as unpinned tabs and accidentally close them.


Expected behavior:

Clear indication for pinned tabs so that users won't accidentally close them.


IMO there should be a separator between pinned and unpinned tabs, perhaps with a small `Pinned tabs` header [similar](https://hg.mozilla.org/mozilla-central/rev/58b73242f3ef#l6.12) [to](https://searchfox.org/mozilla-central/rev/d604c84efdb9efc4c56bb71df6f397897e2b7781/browser/locales/en-US/browser/appmenu.ftl#156) the `Recent history` header in the History (sub)menu. An alternative would be to hide the close tab button for pinned tabs in the drop-down menu by default, although this doesn't make the drag-and-drop issue less confusing.

I could live with a minimal fix where a "ispinnedtab" attribute is added to each pinned `toolbaritem.all-tabs-item` in the drop-down menu (similar to the "[hashiddentabs](https://bugzilla.mozilla.org/show_bug.cgi?id=1924041)" attribute), because AFAICT it's not currently possible for users to specifically target pinned tabs with their own css fix.
Bug: Session restore fails to restore tabs in groups
Status: NEW
Priority: P1
Created: 2025-03-02 22:56:22+00:00
Resolved: 2025-03-04 14:46:21+00:00

Repro steps:
- (Optional) create a new profile to repro this bug -- this makes a mozregression much easier because of profile cloning.
- Open a window and open 2 pages in tabs.
- Assign the second page to a tab group.
- Close Firefox.
- Open Firefox with the same profile.'
- Restore previous session from menus.
- Note that tab(s) in tab group are not restored.
  - This is destructive in that further sessionrestore files written won't include the lost tabs. So users who are relying on sessions and session restore have tabs in groups lost following this.
  - So mitigation means rolling back to an older version of nightly *AND* restoring sessionrestore files written before the bug exists, which is pretty gnarly for most users.

---

mozregression indicates regressing bug is Bug 1948078

```
2025-03-03T11:42:39.311000: DEBUG : Found commit message:
Bug 1948078 - When restore is deferred, convert last session's open groups to saved groups. r=jswinarton,sessionstore-reviewers

Differential Revision: https://phabricator.services.mozilla.com/D239451

2025-03-03T11:42:39.311000: DEBUG : Did not find a branch, checking all integration branches
2025-03-03T11:42:39.312000: INFO : The bisection is done.
2025-03-03T11:42:39.313000: INFO : Stopped
```
Bug: Removal of security.external_protocol_requires_permission affects Fedora Anaconda Web UI installer
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2025-03-03 09:57:43+00:00
Resolved: 2025-03-04 10:31:14+00:00

The recent removal of the security.external_protocol_requires_permission preference in Firefox has negatively impacted the Fedora Anaconda Web UI installer. This installer runs in Firefox and relies on custom mimetype links (e.g., extlink://) to open applications like GNOME Control Center and other system tools.

Previously, we set this option to false to allow external protocol links to open automatically without requiring user confirmation. Now that this preference has been removed, users are prompted every time they attempt to open an external application, significantly affecting the installation experience.

The removal affects Fedora's official installation workflow since Fedora 42, which depends on smooth integration between the web-based installer and system applications.

I ask therefore for this preference to be reinstated or for an alternative solution that allows trusted Web UIs (like Anaconda) to open external applications without confirmation prompts.
Bug: 14.39% rasterflood_gradient (Linux) regression on Thu February 27 2025
Status: ASSIGNED
Priority: --
Created: 2025-03-03 11:58:38+00:00
Resolved: 2025-03-05 17:31:49+00:00

Perfherder has detected a talos performance regression from push [d16cff0d256f48bc57c10d166664b574c9a44afb](https://hg.mozilla.org/integration/autoland/pushloghtml?changeset=d16cff0d256f48bc57c10d166664b574c9a44afb). 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)** |  
|--|--|--|--|--| 
| [14%](https://treeherder.mozilla.org/perfherder/graphs?timerange=1209600&series=autoland,4767291,1,1)  | [rasterflood_gradient](https://firefox-source-docs.mozilla.org/testing/perfdocs/talos.html#rasterflood_gradient)  | linux1804-64-shippable-qr | e10s fission stylo webrender-sw | 1,237.25 -> 1,059.17 | 


Details of the alert can be found in the [alert summary](https://treeherder.mozilla.org/perfherder/alerts?id=44148), 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 44148`

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: 2.79% damp browser-toolbox.styleeditor-ready.DAMP (Windows) regression on Tue February 18 2025
Status: NEW
Priority: --
Created: 2025-03-03 12:18:41+00:00
Resolved: 2025-03-04 14:46:09+00:00

Perfherder has detected a devtools performance regression from push [c894c73bf604ab4b746607fc8affba317ee6e0bd](https://hg.mozilla.org/integration/autoland/pushloghtml?changeset=c894c73bf604ab4b746607fc8affba317ee6e0bd). 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)** |  
|--|--|--|--|--| 
| [3%](https://treeherder.mozilla.org/perfherder/graphs?timerange=1209600&series=autoland,85770,1,12)  | [damp](https://firefox-source-docs.mozilla.org/devtools/tests/performance-tests-overview.html#damp) browser-toolbox.styleeditor-ready.DAMP | windows11-64-shippable-qr | e10s fission stylo webrender | 275.57 -> 283.25 | 


Details of the alert can be found in the [alert summary](https://treeherder.mozilla.org/perfherder/alerts?id=44092), 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 44092`

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: Firefox crashes if restarted or closed during the agent scan
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2025-03-03 14:21:44+00:00
Resolved: 2025-03-05 07:39:03+00:00

**Found in**
* 137.0a1 (20250227215252)



**Affected versions**
* 137.0a1 (20250227215252) 








**Tested platforms**
* Affected platforms:  Windows 10x64, Windows 11
* Unaffected platforms: Ubuntu 24, macOS


**Preconditions**
* Download the DLP test assets from https://drive.google.com/file/d/1yjqVRuxdKV3WnO7D2wzMgDXBuYBxUgVw/view
* Create a distribution folder inside the Firefox folder and paste the policies-1.json to it and then rename it to policies.json
* DLP Agent is running: `.\content_analysis_sdk_agent.exe --user --toblock=.*\d{3}-?\d{2}-?\d{4}.* --towarn=.*warn.* --delays=10`

**Steps to reproduce**
1. Open Firefox and perform clipboard paste.
2. Quit Firefox or restart it from about:profiles.


****Expected result****
* No crash.

**Actual result**
* Firefox crashes.


**Regression range**
*  https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e61476fe62c4783346b97bbb4acc2ea36fce3ab5&tochange=9550881f6afa25df1fba11c16d9a6c5b82709d7f 

**Additional notes**
* Attached a screen recording.
* This may be the same as bug 1950858 but since they had different signatures I filled another one. Please duplicate them if they are the same. Thank you!
* Even if this may be an edge case I will mark it as high impact because of being a recent crash regression. Also, we don't know if this crash may occur in other situations.
Bug: The notification that Firefox is closed during scanning is no longer displayed
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2025-03-03 14:44:30+00:00
Resolved: 2025-03-05 07:38:18+00:00

**Found in**
* 137.0a1 (20250227215252)



**Affected versions**
* 137.0a1 (20250227215252) 








**Tested platforms**
* Affected platforms:  Windows 10x64, Windows 11
* Unaffected platforms: Ubuntu 24, macOS


**Preconditions**
* Download the DLP test assets from https://drive.google.com/file/d/1yjqVRuxdKV3WnO7D2wzMgDXBuYBxUgVw/view
* Create a distribution folder inside the Firefox folder and paste the policies-1.json to it and then rename it to policies.json
* DLP Agent is running: `.\content_analysis_sdk_agent.exe --user --toblock=.*\d{3}-?\d{2}-?\d{4}.* --towarn=.*warn.* --delays=10`

**Steps to reproduce**
1. Open Firefox and perform clipboard paste.
2. Quit Firefox or restart it.


****Expected result****
* The notification that Several actions are in progress is displayed.

**Actual result**
* No notification.


**Regression range**
*  https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=8843913036c5dcf5d523a0af271466672d06e7ca&tochange=d2d88a4e2655a9320280cd2893129f279187d84f

**Additional notes**
* Attached a screen recording.
Bug: Dragging pinned vertical tabs a tiny amount causes them to switch place or move to the end of the pinned tabs list
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2025-03-03 18:19:53+00:00
Resolved: 2025-03-05 11:48:28+00:00

It's currently too easy to accidentally change/break the order of vertical pinned tabs with limited drag movement especially compared to horizontal tabs.

This seems to be regressed by Bug 1950104, in moz-regression I assumed that the bug fixed by 1950104 was a build "good". 

> 2025-03-03T16:59:08.802000: DEBUG : Found commit message:
> Bug 1950104 - Make #moveTabNextTo handle the vertical pinned tabs container. r=nsharpley


STR: 

* Enable vertical tabs with `sidebar.verticalTabs` set to true.
* Create at least 2 pinned tabs
* Move the first one to the right slightly and you'll note it swaps place with the one at the end of the list.
* It's also possible to see the 1st tab move to the end of the list with more tabs e.g. 1st -> 4th position.

What happens:

* It's too easy to accidentally drag a pinned vertical tab and mess up the order of pinned tabs.

What should happen:

 * It should be harder to drag and drop reorder pinned tabs similar to horizontal tabs.
Bug: Firefox crashes when run on Zink
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2025-03-03 22:06:18+00:00
Resolved: 2025-03-03 23:07:29+00:00

Steps to reproduce:

Run firefox on Mesa with MESA_LOADER_DRIVER_OVERRIDE=zink. A very recent build of Zink is recommended as there have been some recent bugfixes there.


Actual results:

Firefox crashes