av9ash/GitBugs huggingface dataset:
Bug: skype web stopped working after update to Firefox 95
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-12-13 05:51:09+00:00
Resolved: 2021-12-13 05:55:30+00:00

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

Steps to reproduce:

go to web.skype.com and log in with my credentials


Actual results:

page stucks up on the loading screen, loading graphics and microsoft logo are displayed only.


Expected results:

skype should open, now Firefox is supported browser by Microsoft.
Bug: Titlebar layout gets weird with lots of pinned tabs + normal tabs + a small window width
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-12-13 08:48:22+00:00
Resolved: 2021-12-27 12:56:30+00:00

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

Steps to reproduce:

1. Pin a lot of tabs
2. Open a normal tab (at least one - I don't know why this breaks it, but it does)
3. Resize the window to be very small


Actual results:

See attachment. Notably:

- arrow buttons overlap each other and the new tab button
- close button is just gone


Expected results:

The buttons are in their right places; less tabs are displayed.
Bug: 81.79% speedometer Preact-TodoMVC/DeletingItems/Sync (Windows) regression on Tue November 23 2021
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2021-12-13 12:15:21+00:00
Resolved: 2022-03-15 13:59:11+00:00

Perfherder has detected a browsertime performance regression from push [0fb0990124cfd4d05e81e3a78971b10525ef5c31](https://hg.mozilla.org/integration/autoland/pushloghtml?changeset=0fb0990124cfd4d05e81e3a78971b10525ef5c31). 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)**| 
|--|--|--|--|--| 
| 82% | [speedometer](https://firefox-source-docs.mozilla.org/testing/perfdocs/raptor.html#speedometer-b) Preact-TodoMVC/DeletingItems/Sync | windows10-64-shippable-qr | webrender | [1.56](https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/adQ142qvTiKC49GMocYhtg/runs/0/artifacts/public/test_info/browsertime-results.tgz) -> [2.83](https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/CyjcsmplQC6zoctA7NyDaw/runs/0/artifacts/public/test_info/browsertime-results.tgz) |


Details of the alert can be found in the [alert summary](https://treeherder.mozilla.org/perfherder/alerts?id=32711), 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 offending patch(es) will be backed out** in accordance with our [regression policy](https://www.mozilla.org/en-US/about/governance/policies/regressions/).

For more information on performance sheriffing please see our [FAQ](https://wiki.mozilla.org/TestEngineering/Performance/FAQ).
Bug: Insecure connection icon is barely visible on http website login form with dark theme
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2021-12-13 14:23:22+00:00
Resolved: 2025-01-10 11:26:29+00:00

*Affected versions*
* 97.0a1 (20211213093143)
* 96.0b4 (20211212185725)
* 95.0 (20211129150630)
* 91.4.0esr (20211126104708)





*Affected platforms*

* macOS 11.6

*Preconditions*
* dark theme enabled

*Steps to reproduce*
1. Open Firefox and http://jsbin.testim.io/soviruvalo/1/edit?html,output.
2. Click on the username/ password form and observe the insecure icon.







*Expected result*
*  The icon is visible.


*Actual result*
* The lock icon is barely visible.

*Regression range*
*  Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b8b54a4990d7e778b82909a871e92031a4bc649d&tochange=4b3932f9c4f5d9572da2f0232375474133191500
Potential regressor: bug 1715619. 














*Notes*
* Screenshot attached.
Bug: Crash in [@ RtlAcquireSRWLockExclusive]
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-12-13 14:34:19+00:00
Resolved: 2021-12-21 10:52:57+00:00

Crash report: https://crash-stats.mozilla.org/report/index/b7c11d26-92d9-4d67-859d-8a1e50211207

Reason: ```EXCEPTION_ACCESS_VIOLATION_WRITE```

Top 1 frames of crashing thread:
```
0 ntdll.dll RtlAcquireSRWLockExclusive 
```
Bug: context menu does not pass on the target name any more
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-12-13 16:21:15+00:00
Resolved: 2021-12-20 16:05:33+00:00

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

Steps to reproduce:

open Firefox
- find any page with a link, which leads not only to a page, but to a target there, e.g.:
https://www.gutefrage.net/frage/kann-mir-jemand-diese-aufgabe-erklaeren-39#comment-324097397
- context menu = right klick at this link and use "open in a new tab



Actual results:

it is opened
https://www.gutefrage.net/frage/kann-mir-jemand-diese-aufgabe-erklaeren-39


Expected results:

it shall be opened
https://www.gutefrage.net/frage/kann-mir-jemand-diese-aufgabe-erklaeren-39#comment-324097397

so in other words: The target is not jumped to, but only the link itsself is opened.

This was true from about FF 94 and is still true in FF 95.0 the most recent update.
Bug: Firefox renders some mime type as HTML which is not observed in other modern browsers
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-12-14 05:04:31+00:00
Resolved: 2024-09-16 05:23:43+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.55 Safari/537.36

Steps to reproduce:

The Safari web browser renders the following mime type as HTML:

application/mathml+xml
application/rdf+xml

No other modern browser does this (Tested against Google Chrome, Safari and Edge)

PoC is attached in the report.


Actual results:

The content was rendered as HTML and the Javascript was executed. This resulted in XSS in a web application I was testing.


Expected results:

The content should not be rendered as HTML (observed behaviour in other browsers)
Bug: Restarting Mac with "Open all windows currently open" does not open current tabs work
Status: UNCONFIRMED
Priority: --
Created: 2021-12-14 06:29:08+00:00
Resolved: 2024-05-17 10:06:34+00:00

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

Steps to reproduce:

For my scientific research, I opened over 20 Tabs with scripts, books, studies. This took me hours to prepare and it's literally all gone. 
I left the tabs open in the background, minimized. I was using firefox in a new tab-group all the other days and left my research in the background.  About one week later, I had to restart my macbook: I chose "Beim nächsten Anmelden alle Fenster wieder öffnen" -> "Open all windows again at the next login".


Actual results:

Absolutely nothing happened. Firefox opened and greeted me with a cheeky "THANKS FOR UPDATING THE NEWEST VERSION". I wasn't even approving an update - because of reasons like these that just create more and more problems with new updates. All my research progress is literally lost and gone.


Expected results:

Do what literally every other browser would've done properly. Locally save the tabs I had opened and open them again if I choose "Open all windows again at the next login". Also, why would someone at firefox propose the idea to LITERALLY REMOVE the option for firefox users to open closed tab groups with this update. A couple versions this worked fine. Now with this new update i can literally not even reopen the tab groups I closed.
Bug: The "VPN Moments Page 13" is wrongly triggered even if the "Firefox Multi-Account Containers" extension is installed
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2021-12-14 12:45:27+00:00
Resolved: 2022-01-03 17:28:16+00:00

**[Affected versions]:**
- Firefox Release 95.0 - Build ID: 20211129150630

**[Affected Platforms]:**
- Windows 10 x64
- macOS 11.6.1

**[Prerequisites]:**
- Have the latest Firefox Release 95.0 en-US locale installed.
- Have a Firefox profile with the latest version of the "Firefox Multi-Account Containers" (8.0.3) installed.
- Have the "browser.search.region" pref set to "US" in the "about:config" page.
- Have the latest version of the "Remote Settings Devtools" add-on installed from [here](https://github.com/mozilla-extensions/remote-settings-devtools/releases/download/1.6.0/remote-settings-devtools.xpi).

**[Steps to reproduce]:**
1. Open the browser with the profile from the prerequisites.
2. Click the "Remote Settings Devtools" toolbar button from the right part of the "Address Bar". 
3. Change the environment to "Stage" and restart the browser.
4. Restart the browser again and observe the behavior.

**[Expected result]:**
- The "VPN Moments Page 12" is triggered.
 
**[Actual result]:**
- The "VPN Moments Page 13" is triggered instead.

**[Notes]:**
- Also, I've checked the targeting of the "VPN Moments Page 12" in the "AS Router Admin" page and it appears that is valid but the "VPN Moments Page 13" is triggered first.
- Attached a screen recording of the issue.
Bug: The "VPN Moments Page 11" is triggered instead of the "VPN Moments Page 13" one if both pages are active
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2021-12-14 13:13:41+00:00
Resolved: 2021-12-31 10:47:45+00:00

**[Affected versions]:**
- Firefox Release 95.0 - Build ID: 20211129150630

**[Affected Platforms]:**
- Windows 10 x64
- macOS 11.6.1

**[Prerequisites]:**
- Have the latest Firefox Release 95.0 en-US locale installed.
- Have the "browser.search.region" pref set to "US" in the "about:config" page.
- Have the latest version of the "Remote Settings Devtools" add-on installed from [here](https://github.com/mozilla-extensions/remote-settings-devtools/releases/download/1.6.0/remote-settings-devtools.xpi).

**[Steps to reproduce]:**
1. Open the browser with the profile from the prerequisites.
2. Click the "Remote Settings Devtools" toolbar button from the right part of the "Address Bar". 
3. Change the environment to "Stage" and restart the browser.
4. Restart the browser again and observe the behavior.

**[Expected result]:**
- The "VPN Moments Page 13" is triggered.
 
**[Actual result]:**
- - The "VPN Moments Page 11" is triggered instead.

**[Notes]:**
- This issue is also reproducible with "VPN Moments Page 10".
- If the "VPN Moments Page 10" and  "VPN Moments Page 11" are blocked in the "ASRouter" page, then the "VPN Moments Page 13" is successfully triggered. Considering this we suggest stopping the "VPN Moments Page 10" and  "VPN Moments Page 11" before launching the new "VPN Moments Page 12" and  "VPN Moments Page 13".
- Attached a screen recording of the issue.
Bug: getTabDialogBox should not fall back to selected browser
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-12-14 14:40:36+00:00
Resolved: 2021-12-17 03:55:59+00:00

Currently `gBrowser.getTabDialogBox` will fall back to the selected browser if no `browser` argument is given. This can lead to unexpected behavior. We should instead require callers to pass a browser explicitly.

https://searchfox.org/mozilla-central/rev/71befbc9bc348d33f0c7307dc48e3cb36ba78650/browser/base/content/tabbrowser.js#869
Bug: Intermittent browser/components/preferences/tests/browser_search_subdialogs_within_preferences_5.js | A promise chain failed to handle a rejection: data.args.deserialize is not a function - stack: recvRunListener@resource://gre/modules/ExtensionChild.
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2021-12-14 15:32:56+00:00
Resolved: 2022-01-11 17:08:16+00:00

**Filed by:** archaeopteryx [at] coole-files.de
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=361178146&repo=try
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/OwH-ez52TzOWbLlfYgDrXQ/runs/0/artifacts/public/logs/live_backing.log

---
```
[task 2021-12-14T12:51:27.476Z] 12:51:27     INFO - TEST-PASS | browser/components/preferences/tests/browser_search_subdialogs_within_preferences_5.js | advanced should not be in search results - 
[task 2021-12-14T12:51:27.476Z] 12:51:27     INFO - Buffered messages finished
[task 2021-12-14T12:51:27.478Z] 12:51:27     INFO - TEST-UNEXPECTED-FAIL | browser/components/preferences/tests/browser_search_subdialogs_within_preferences_5.js | A promise chain failed to handle a rejection: data.args.deserialize is not a function - stack: recvRunListener@resource://gre/modules/ExtensionChild.jsm:824:28
[task 2021-12-14T12:51:27.478Z] 12:51:27     INFO - _recv@resource://gre/modules/ConduitsChild.jsm:82:20
[task 2021-12-14T12:51:27.478Z] 12:51:27     INFO - receiveMessage@resource://gre/modules/ConduitsChild.jsm:188:20
[task 2021-12-14T12:51:27.478Z] 12:51:27     INFO - Rejection date: Tue Dec 14 2021 12:51:26 GMT+0000 (Coordinated Universal Time) - false == true - JS frame :: resource://testing-common/PromiseTestUtils.jsm :: assertNoUncaughtRejections :: line 271
[task 2021-12-14T12:51:27.478Z] 12:51:27     INFO - Stack trace:
[task 2021-12-14T12:51:27.478Z] 12:51:27     INFO - resource://testing-common/PromiseTestUtils.jsm:assertNoUncaughtRejections:271
[task 2021-12-14T12:51:27.479Z] 12:51:27     INFO - chrome://mochikit/content/browser-test.js:Tester_execTest/<:1161
[task 2021-12-14T12:51:27.479Z] 12:51:27     INFO - Leaving test bound 
```
Bug: The bookmarks sidebar freezes sometimes
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-12-14 16:04:59+00:00
Resolved: 2022-01-27 16:47:18+00:00

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

Steps to reproduce:

Nothing in particular. It seems to happen anytime, randomly.



Actual results:

The bookmark panel freezes. It cannot be expanded or collapsed, and clicking on an element does not open the link.

To palliate the issue, I close and re-open the bookmark panel (Ctl-B, Ctl-B) and now the panel works correctly.


Expected results:

The bookmark panel should respond as expected: can be expanded or collapsed and responds to clicks to open links.
Bug: Border of the active tab is displayed differently between default theme and custom theme
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2021-12-14 16:38:57+00:00
Resolved: 2022-08-11 16:14:12+00:00

Steps to reproduce:
  1. run Nightly 97.0a1 (2021-12-14) (64-bit) on macOS, with clean profile
  2. go to https://addons.mozilla.org/en-US/firefox/addon/a-n-i-m-a-t-e-d-kitty-cat/
  3. click "Install Theme" and "Add"

Actual result:
active tab's has black border, that doesn't match the remaining of the UI, nor the default theme's where it has gray border

Expected result:
active tab has gray border, or any color of border that matches the remaining of the UI

Regression range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ac52da65f48fb66f9df0c93a33fb57ba3bb68465&tochange=965bf155a9db49ce7ec1533b3b8eee2901a79d4e
Bug: refiling of a URL selected from history libary
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-12-14 18:19:33+00:00
Resolved: 2022-01-05 16:44:03+00:00

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

Steps to reproduce:

From the History Library pick a bookmark from "Yesterday" 
The same bookmark, after opening, is collected back in the bookmark's History Library under 'Yesterday'....it should be under 'Today'

This may also be the case for other sections than "Yesterday" but I have not checked


Actual results:

After SELECTING the URL from yesterday's history, the URL appearED at the top of YESTERDAY's history


Expected results:

After SELECTING the URL from yesterday's history, the URL should reappear at the top of TODAY's history
Bug: Unify ways to select and validate filenames when saving
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2021-12-14 18:44:12+00:00
Resolved: 2023-02-20 10:15:14+00:00

There are at least five different ways in which one can save a file such as an image. However they all use different codepaths that determine the filename differently, and apply different validation rules to the filename.

1. Save As
 - does use the filename from the content-disposition, but also uses the 'name' if it is not present.
 - uses the document title if available
 - replaces some invalid extensions but for other invalid extensions, just appends to the existing one (reallyapng.jpeg becomes reallyapng.png but image.pang becomes image.pang.png)
 - strips out many illegal characters (more so than drag and copy)
 - does not truncate long filenames (such that on Mac, the save button is just disabled and it is unclear why)
 
2. Subfiles saved from save document, complete:
 - doesn't use the filename from the content-disposition
 - replaces invalid extensions
 - truncates long filenames to a maximum of 64 characters
 - strips out almost all non-alphanumeric characters
 - if the file already exists, adds a number such as '_001', '_002' etc. to the filename

3. Drag image to file system:
 - doesn't use the filename from the content-disposition
 - replaces invalid extensions
 - strips out some illegal characters
 - does not truncate long filenames
 - Mac uses different but identical code for this

4. Copy/Paste image to file system
 - doesn't use the filename from the content-disposition
 - replaces invalid extensions
 - strips out some illegal characters
 - does not truncate long filenames

5. Content-disposition: attachment or download attribute
 - filename from the content-disposition overrides the download attribute (this is the correct behaviour)
 - doesn't replace invalid extensions
 - strips out some illegal characters (a yet still different set than the other types)
 - truncates long filenames to a maximum to 138(?) characters

There are other various minor differences. It would be good to unify all of these so that they same rules apply in each case.
Bug: PDF is cut off when opening it on external monitor in mac
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-12-14 19:15:42+00:00
Resolved: 2022-03-25 17:03:07+00:00

Steps to reproduce:

Open firefox (or firefox nightly) on the macbook (macbook pro 13 inch 2017, macOS Monterey version 12.0.1).
Drag the window to an external monitor (connected through an hdmi hub)
Draw the window to the laptop.
Open a pdf file. 


Actual results:

PDF opens on the external monitor, but cut off, like it was resized. (i attached a video filming the bug on the external monitor)


Expected results:

PDF should open normal
Bug: Pocket newtab Nimbus listener update event not properly removed
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-12-14 19:53:13+00:00
Resolved: 2021-12-17 03:56:06+00:00

Looks like when we call off on the update even for Pocket newtab's Nimbus event, it's being called on the wrong item.
Bug: Intermittent TV browser/components/sessionstore/test/browser_backup_recovery.js | After second write, clean shutdown sessionstore doesn't exist, since we haven't shutdown yet -
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2021-12-15 04:32:29+00:00
Resolved: 2024-02-19 12:03:07+00:00

**Filed by:** imoraru [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=361261742&repo=autoland
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Av9HZm-jS-KZQcNQCn639w/runs/0/artifacts/public/logs/live_backing.log
**Reftest URL:** https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Av9HZm-jS-KZQcNQCn639w/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1

---
```
[task 2021-12-15T02:04:12.762Z] 02:04:12     INFO - TEST-PASS | browser/components/sessionstore/test/browser_backup_recovery.js | After second write, clean shutdown sessionstore doesn't exist, since we haven't shutdown yet - 
[task 2021-12-15T02:04:12.762Z] 02:04:12     INFO - Buffered messages finished
[task 2021-12-15T02:04:12.763Z] 02:04:12     INFO - TEST-UNEXPECTED-FAIL | browser/components/sessionstore/test/browser_backup_recovery.js | After second write, clean shutdown sessionstore doesn't exist, since we haven't shutdown yet - 
[task 2021-12-15T02:04:12.763Z] 02:04:12     INFO - Stack trace:
[task 2021-12-15T02:04:12.763Z] 02:04:12     INFO - chrome://mochikit/content/browser-test.js:test_ok:1375
[task 2021-12-15T02:04:12.763Z] 02:04:12     INFO - chrome://mochitests/content/browser/browser/components/sessionstore/test/browser_backup_recovery.js:test_creation:131
[task 2021-12-15T02:04:12.764Z] 02:04:12     INFO - TEST-PASS | browser/components/sessionstore/test/browser_backup_recovery.js | After second write, clean shutdown sessionstore doesn't exist, since we haven't shutdown yet - 
```
Bug: Latest Firefox version throws an error using Firebase API for Cloud Messaging
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-12-15 13:28:31+00:00
Resolved: 2021-12-16 10:40:43+00:00

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

Steps to reproduce:

Hi, I'm using the Firebase Cloud Messaging API which always worked fine in Firefox, untill I upgrade to the latest Firefox version 91.4.0esr (64 bit) available for my Mac computer, then they stopped working.
FYI, my Mac is 10.14.6 (18G103) macOSMojave

The latest Firebase Cloud Messaging API (namespace compatible) 8.10.0 are used too.



Actual results:

When running the Firebase Cloud Messaging API (using HTTPS), I get the following error in the console:

This browser doesn't support the API's required to use the firebase SDK. (messaging/unsupported-browser).

Please note nothing else has changed code or infrastructure wise.



Expected results:

Firefox should run the Firebase Cloud Messaging API to use the Web Push API for Notifications as usual, instead of returning the error in the latest Firefox version.
If  working correctly,  Firefox should have promted the user to allow/disallow Notifications.
Bug: An extra blank space is displayed at the bottom of the about:logins page after a new login is saved
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2021-12-15 13:45:17+00:00
Resolved: 2022-01-19 13:15:21+00:00

**Affected versions**
- 97.0a1 (2021-12-15)
- 96.0b5

**Affected platforms**
- Windows 10
- Ubuntu 16.04
- macOS 10.14

**Steps to reproduce**
1. Open the about:logins page
2. Click on the Create New Login button
3. Provide relevant information inside the required fields
4. Click on the Save button
5. Scroll down the page a little bit

**Expected result**
- No unnecessary space is displayed on the page.

**Actual result**
 - An extra blank space is displayed at the bottom of the page.

**Regression range**
- Last good revision: 5fe3c617d521ed21ffd41b8060dc1351e90650d1
- First bad revision: ef598c9dc54b222d8420286fbba72533c57d8505
- Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5fe3c617d521ed21ffd41b8060dc1351e90650d1&tochange=ef598c9dc54b222d8420286fbba72533c57d8505
- Regressor bug: 1739390

**Other notes**
- No functionality seams to be affected.