av9ash/GitBugs huggingface dataset:
Bug: Perma a11y [Tier2] browser/components/translations/tests/browser/browser_translations_about_preferences_settings_ui.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2024-04-10 20:46:12+00:00
Resolved: 2024-04-29 06:15:43+00:00

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

---
```
TEST-PASS | browser/components/translations/tests/browser/browser_translations_about_preferences_settings_ui.js | Number of languages added is 4 - 
[task 2024-04-10T20:27:46.999Z] 20:27:46     INFO - Buffered messages finished
[task 2024-04-10T20:27:47.001Z] 20:27:47     INFO - TEST-UNEXPECTED-FAIL | browser/components/translations/tests/browser/browser_translations_about_preferences_settings_ui.js | Node is not accessible via accessibility API: id: , tagName: moz-button, className: translations-settings-delete-icon - 
[task 2024-04-10T20:27:47.001Z] 20:27:47     INFO - Stack trace:
[task 2024-04-10T20:27:47.001Z] 20:27:47     INFO - chrome://mochikit/content/browser-test.js:test_ok:1592
[task 2024-04-10T20:27:47.001Z] 20:27:47     INFO - chrome://mochikit/content/tests/SimpleTest/AccessibilityUtils.js:a11yFail:752
[task 2024-04-10T20:27:47.001Z] 20:27:47     INFO - chrome://mochikit/content/tests/SimpleTest/AccessibilityUtils.js:assertCanBeClicked:1161
[task 2024-04-10T20:27:47.001Z] 20:27:47     INFO - chrome://mochikit/content/tests/SimpleTest/AccessibilityUtils.js:runIfA11YChecks/this.AccessibilityUtils:1137
[task 2024-04-10T20:27:47.001Z] 20:27:47     INFO - chrome://mochikit/content/tests/SimpleTest/AccessibilityUtils.js:handleEvent:1254
[task 2024-04-10T20:27:47.001Z] 20:27:47     INFO - chrome://mochitests/content/browser/browser/components/translations/tests/browser/browser_translations_about_preferences_settings_ui.js:testLanguageList:164
[task 2024-04-10T20:27:47.001Z] 20:27:47     INFO - chrome://mochitests/content/browser/browser/components/translations/tests/browser/browser_translations_about_preferences_settings_ui.js:test_translations_settings_always_translate:110
[task 2024-04-10T20:27:47.001Z] 20:27:47     INFO - chrome://mochikit/content/browser-test.js:handleTask:1139
[task 2024-04-10T20:27:47.001Z] 20:27:47     INFO - chrome://mochikit/content/browser-test.js:_runTaskBasedTest:1211
[task 2024-04-10T20:27:47.001Z] 20:27:47     INFO - chrome://mochikit/content/browser-test.js:Tester_execTest:1353
[task 2024-04-10T20:27:47.002Z] 20:27:47     INFO - chrome://mochikit/content/browser-test.js:nextTest/<:1128
[task 2024-04-10T20:27:47.002Z] 20:27:47     INFO - chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:SimpleTest.waitForFocus/<:1058
[task 2024-04-10T20:27:47.002Z] 20:27:47     INFO - TEST-PASS | browser/components/translations/tests/browser/browser_translations_about_preferences_settings_ui.js | Ukrainian removed from Always  Translate - 
```
Bug: Login page hangs for xcelenergy.com and others starting with 124.0.2 (64-bit)
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-04-10 21:45:25+00:00
Resolved: 2024-04-17 20:16:13+00:00

Steps to reproduce:

visit xcelenergy.com, click on Sign In.


Actual results:

Site redirects to https://co.my.xcelenergy.com/s/.
Blank page displays forever.


Expected results:

Display Sign In page and accept log in credentials.
Bug: Fix "Choose a language" regression in FullPageTranslationsPanel
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2024-04-11 00:49:23+00:00
Resolved: 2024-05-10 13:14:12+00:00

### Description

In Bug 1870316 (revision [D204975](https://phabricator.services.mozilla.com/D204975)) I introduced behavior that [removes items from the translations panel menu lists](https://searchfox.org/mozilla-central/rev/1f27a4022f9f1269d897526c1c892a57743e650c/browser/components/translations/content/TranslationsPanelShared.sys.mjs#117-119) by default when they are initialized. This way tests can clear and reset all of the initialized values between tests. 

This works well for the Select Translations Panel, which is designed to localize the menu list labels with "Choose a language" if no value is selected.

However, for the Full Page Translations Panel, the "Choose a language" value is actually a selectable menu item in the menu-list dropdown, and this code is causing that item to be removed from the lists. 

This will need to be fixed in a way that works for both panel implementations.

---

### Steps to Reproduce Issue #1

* Open a fresh browser window.
* Go to the website https://gl.wikipedia.org (a language that we do not support for translation at the time of writing).
* Click the Application Menu (hamburger icon at the top corner of the browser UI).
* Navigate to the "Translate this page..." menu item and click it.
* When prompted that this language is not supported, click the "Choose another source language" button.

**Expected Behavior**
The "Translate From" menu list value should be set to "Choose a language"

**Actual Behavior**
The "Translate From" menu list value is set to Bulgarian (the first language in the list at the time of writing).

---

### Steps to Reproduce Issue #2

* Open a fresh browser window.
* Go to the website https://es.wikipedia.org (a language that we **do** support for translation at the time of writing).
* Wait for the FullPageTranslationsPanel to open. It should open automatically. 
* Go to the website https://gl.wikipedia.org (a language that we **do not** support for translation at the time of writing).
* Click the Application Menu (hamburger icon at the top corner of the browser UI).
* Navigate to the "Translate this page..." menu item and click it.
* When prompted that this language is not supported, click the "Choose another source language" button.

**Expected Behavior**
The "Translate From" menu list value should be set to "Choose a language"

**Actual Behavior**
The "Translate From" menu list value blank, when it should have a value.
Bug: [macOS] A white outline can be seen on Firefox menus on darker backgrounds
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2024-04-11 10:54:52+00:00
Resolved: 2024-05-31 17:20:26+00:00

**Found in**
* 126.0a1 (2024-04-10)

**Affected versions**
* 126.0a1 (2024-04-10)

**Tested platforms**
* Affected platforms: macOS 14, 12
* Unaffected platforms: Windows 10x64, Ubuntu 23.10

**Preconditions**
* System dark theme enabled on macOS
* System theme enabled in Firefox

**Steps to reproduce**
1. Open https://www.wikipedia.org/ and click on the shield icon from the URL Bar.
2. Open https://twitter.com/ and click on the shield icon from the URL Bar.

**Expected result** 
* Step1&2: No white outline is visible

**Actual result**
* Step1: A white line is visible only on the top part of the Protections menu due to the white Wikipedia page
* Step2: A white line is visible surrounding all Protections menu due to the dark Twitter page.


**Regression range**
*Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=7f2993771f48536c575137e4b51984ab6d3de136&tochange=17e12c4e0af6ca51b74feadaae77603c960888de 
Possible regressor: bug 1886729

**Additional notes**
* Attached a screen shot.
* This can be seen across all URL bar panels.
* If this is expected feel free to close this as invalid. Thank you!
Bug: Intermittent browser/base/content/test/contextMenu/browser_contextmenu_iframe.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2024-04-11 12:43:06+00:00
Resolved: 2024-08-21 12:05:06+00:00

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

---
```
[task 2024-04-11T10:40:07.968Z] 10:40:07     INFO - TEST-PASS | browser/base/content/test/contextMenu/browser_contextmenu_iframe.js | checking if popup is closed - 
[task 2024-04-11T10:40:07.969Z] 10:40:07     INFO - Buffered messages finished
[task 2024-04-11T10:40:07.970Z] 10:40:07     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/contextMenu/browser_contextmenu_iframe.js | Test timed out - 
[task 2024-04-11T10:40:07.970Z] 10:40:07     INFO - GECKO(8732) | Completed ShutdownLeaks collections in process 1240
[task 2024-04-11T10:40:07.971Z] 10:40:07     INFO - TEST-START | Shutdown
```
Bug: Tab previews steal keyboard focus
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-04-11 15:24:05+00:00
Resolved: 2024-05-10 07:53:35+00:00

If you're typing and then accidentally move the mouse over a tab when the tab preview pops up it steals focus. Perhaps we should disable previews when in an input box?
Bug: show more accurate experiment dates in Skylight
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2024-04-11 18:08:24+00:00
Resolved: 2024-04-24 15:24:36+00:00

Lots of dates in messaging experiments are either missing or no longer current because, from what I can tell, that part of the remote-settings JSON stops being updated at some point.  My suspicion is that we'll get corrected dates for free once we implement [skylight-experimenter-api](bug 1891093), on which this bug depends.
Bug: some Skylight screenshot links are broken
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2024-04-11 18:16:36+00:00
Resolved: 2024-05-09 14:04:00+00:00

Currently, branch screenshots link to an anchor on the Experimenter page which may or may not actually exist, and in the case where they don't, the link clicks through to the top of the Experimenter page, which we've gotten user feedback is confusing & frustrating.

This is in support of a user story along the lines of, "As a leader or PM, I should be able to quickly access screenshots for each branch that has them, so that I can easily get a sense of what a branch is visually about".

At the moment, the idea is to just fix the broken link. In the future, I suspect we're going to want to experiment with some other possibilities for this user story (like showing the screenshot in a popup on hover or an expandable area inline). To support various experiments, we'll request that the Experimenter API expose an array of the screenshot URIs for each branch.

Next step here is to file the Experimenter ticket.
Bug: Perma Documentation ./mach doc | Error: 1 new warnings have been introduced compared to the limit in docs/config.yml
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2024-04-11 18:24:19+00:00
Resolved: 2024-04-15 19:04:44+00:00

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

---
```
[task 2024-04-11T17:55:59.106Z] /builds/worker/checkouts/gecko/docs-out/html/_staging/toolkit/components/messaging-system/docs/TriggerActionSchemas/index.md:47: WARNING: 'myst' cross-reference target not found: 'deeplinkedToWindowsSettingsUI' [myst.xref_missing]
[task 2024-04-11T17:55:59.133Z] /builds/worker/checkouts/gecko/docs-out/html/_staging/toolkit/components/messaging-system/docs/index.rst:150: WARNING: undefined label: 'run_make_schemas_'
<...>
[task 2024-04-11T17:56:08.488Z] dumping search index in English (code: en)... done
[task 2024-04-11T17:56:08.590Z] dumping object inventory... done
[task 2024-04-11T17:56:08.590Z] build succeeded, 888 warnings.
[task 2024-04-11T17:56:08.590Z] 
[task 2024-04-11T17:56:08.590Z] The HTML pages are in docs-out/html.
[task 2024-04-11T17:56:08.615Z] TEST-UNEXPECTED-FAILURE | ./mach doc | Error: 1 new warnings have been introduced compared to the limit in docs/config.yml
[task 2024-04-11T17:56:08.615Z] 
[task 2024-04-11T17:56:08.615Z] Generated documentation:
[task 2024-04-11T17:56:08.615Z] docs-out/html
[task 2024-04-11T17:56:08.615Z] Logged 838 warnings
[task 2024-04-11T17:56:08.615Z] 
[taskcluster 2024-04-11 17:56:15.616Z] === Task Finished ===
```
Bug: FxA and sync servers get a "B" on SSLlabs tests
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2024-04-11 19:10:09+00:00
Resolved: 2024-07-16 16:03:29+00:00

The core servers for the FxA connected experience all get a "B" rating from SSLLabs, e.g:

  https://www.ssllabs.com/ssltest/analyze.html?d=accounts.firefox.com
  https://www.ssllabs.com/ssltest/analyze.html?d=token.services.mozilla.com

The reason it gives is that:

  "This server supports weak Diffie-Hellman (DH) key exchange parameters.
   Grade capped to B."

Sadly I don't think we can do anything about that yet, but I wanted a bug on file to track it (and to point at when this topic comes up again).

The reasoning behind the current situation is that we have certain clients (e.g. old android devices, partner devices like Bug 1186900) that do not support the "modern" TLS configuration recommended in [1].  Instead we must use the "intermediate" configuration [2] which includes DH ciphers.

These ciphers are fine *if* you use secure DH parameters.  But the TLS support for FxA and Sync is provided by Amazon's Elastic Load Balancers, which don't let you customize the DH parameters.

So I think we're stuck on a "B" grade until all our clients grow more modern TLS support, or Amazon gives us better tools to customize TLS on the ELBs.

[1] https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility
[2] https://wiki.mozilla.org/Security/Server_Side_TLS#Intermediate_compatibility_.28default.29
Bug: primary password
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-04-12 06:55:55+00:00
Resolved: 2024-04-12 07:26:00+00:00

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

Steps to reproduce:

I set primary password to prevent anybody to open mozila firefox browser.


Actual results:

When I open Mozila Firefox browser, a primary password prompt dialog box open to enter password. But If just click on Cancel button of this box instead of enter password and click on sign in button, then dialog box for password just disappear and the firefox browser is accessible to use without any password. and anybody can access all my bookmark, saved information firefox broser without knowing my primary password by just pressing cancel button.


Expected results:

If someone press cancel button on primary password dialog box for open mozila firefox browser then a new browser should be open with blank profile and without any saved bookmark and any saved information.
Bug: Tabs not restored when FireFox restarted (Mac version)
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2024-04-12 06:56:30+00:00
Resolved: 2024-05-06 23:54:08+00:00

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

Steps to reproduce:

I had many tabs open, about 52.  I closed FireFox and shut down my Mac.


Actual results:

When I booted up again, and started FireFox, all tabs were gone except for one, which was opened to Google.  I then used History > Recently Closed Tabs > Reopen All Tabs, which brought back the tabs; however, they were in the reverse order.


Expected results:

Should work normally as it did in past versions.  This is the second time recently that I've seen this happen.  The first time I had 100s of tabs open.

Something must have changed in a recent update for Mac version.
Bug: I cannot sign in on my Mozilla account on my laptop
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-04-12 08:08:17+00:00
Resolved: 2024-10-24 09:36:41+00:00

I can't sign in and I have been waiting for for half a day that I needed to use chrome for my things instead of firefox and I've tried restarting it, refreshing it and checking to see if it works on my phone and it works on my phone but not on my laptop
Bug: Firefox Dev 125.0b9 "Failed to check for updates"
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-04-12 12:51:58+00:00
Resolved: 2024-04-29 17:32:59+00:00

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

Steps to reproduce:

Updated to Firefox Dev 125.0b9 (64-bit) on Win 11 22635.5430.


Actual results:

Firefox About box shows "Failed to check for updates". Additionally if you try Settings > General > Firefox Developer Addition Updates : Check For Updates, the result is "Failed to check for updates."
Logs have following message - 
ASRouter: CheckBrowserNeedsUpdate failed :>>  
XMLHttpRequest { readyState: 4, timeout: 0, withCredentials: false, upload: XMLHttpRequestUpload, responseURL: "https://aus5.mozilla.org/update/6/Firefox/125.0/20240405130120/WINNT_x86_64-msvc-x64/en-US/aurora/Windows_NT%252010.0.0.0.22635.3430%2520(x64)/ISET%3ASSE4_2%2CMEM%3A32179/default/default/update.xml?force=1", status: 0, statusText: "", responseType: "", response: "", responseText: "" }
ASRouterTargeting.sys.mjs:270
Bug: JavaScript sort() returns invalid result
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-04-12 13:10:26+00:00
Resolved: 2024-04-12 13:28:07+00:00

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

Steps to reproduce:

There is something odd with the sort fn in JS


```js
/**
 * 256K > ES (256 > 384 > 512) > PS (256 > 384 > 512) > RS (256 > 384 > 512) > other (in original order)
 */
function compareAlgos(a, b) {
  if (a === 'ES256K') return -1
  if (b === 'ES256K') return 1

  for (const prefix of ['ES', 'PS', 'RS']) {
    if (a.startsWith(prefix)) {
      if (b.startsWith(prefix)) {
        const aLen = parseInt(a.slice(2, 5))
        const bLen = parseInt(b.slice(2, 5))
        console.log(a, b, aLen - bLen)
        return aLen - bLen
      }
      console.log(a, b, -1)
      return -1
    }
  }

  console.log(a, b, 0)
  return 0
}


var algs = [ "RS256", "RS384", "RS512", "PS256", "PS384", "PS512", "ES256", "ES256K", "ES384", "ES512" ]
var algsSorted = [...algs].sort(compareAlgos);

```


Actual results:

[ "ES256K", "RS256", "RS384", "RS512", "PS256", "PS384", "PS512", "ES256", "ES384", "ES512" ]

It seems to be caused by the fact that, given the original order, the sort fn always returns a negative value.


Expected results:

[
  'ES256K', 'ES256',
  'ES384',  'ES512',
  'PS256',  'PS384',
  'PS512',  'RS256',
  'RS384',  'RS512'
]

Safari (17.4.1) Node (21.7.2) & Chrome (123.0.6312.107) all return this
Bug: Regression: Default Theme Selection is confusing
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2024-04-12 14:05:37+00:00
Resolved: 2024-04-25 10:53:07+00:00

Nightly 126.0a1 (2024-04-12) (64-Bit)
macOS 14.4.1

1.) Use System Dark Mode
2.) Select System-Theme-Automatic in Nightly
3.) Select Dark Theme in Nightly

Actual: There are two different styles of Dark Themes.
Expected: There should a decision for a final Dark Theme. I personally prefer the old Dark Theme, which matches more the OS-Style. The new more greyish Dark Theme could be an extra default delivered Theme like you do it with Alpenglow.

Same happens when you in System Light Mode. System-Theme-Automatic looks different to the Light Theme that you can single select. Same here, the older Light Theme matches more with the OS style. The newer Light Theme is too bright in my opinion.

Thanks for listening.
Bug: Dynamic Theme causing browser.tabs.cardPreview to be transparent and difficult to see/read
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-04-12 14:13:41+00:00
Resolved: 2024-04-12 16:24:04+00:00

There seems to be a bug in Firefox 126 Nightly in which a Dynamic (animated) theme seems to cause the browser.tabs.cardPreview to appear transparent when you hover over a tab, This makes it quite unreadable
Bug: New Dark Mode Toolbar border and Address Bar border is too bright
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-04-12 15:04:42+00:00
Resolved: 2024-04-13 23:14:16+00:00

Nightly 126.0a1 (2024-04-12) (64-Bit)
macOS 14.4.1

1.) Use System Dark Mode
2.) Select System-Theme-Automatic in Nightly
3.) Take a look at the Toolbar border color
4.) Type something into the Adress Bar and take a look at the Address Bar border color

Actual: The border is too bright and the browser feels like the System is Accessibility Mode.

Expected: To see darker borders. 

A screenshot is attached.

Thanks for checking.
Bug: [RTL] Screenshot's pixel counter misplaced the 'x' separator
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-04-12 15:54:02+00:00
Resolved: 2024-04-25 14:24:34+00:00

**Found in**
* Nightly 126.0a1

**Affected versions**
* Nightly 126.0a1

**Tested platforms**
* Affected platforms: Windows 10 x64, Ubuntu 22.04 and macOS 13 

**Preconditions**
* install an RTL build - ar in my case.

**Steps to reproduce**
1. Enable Screenshots by pressing the Cmd+Shift+S keys.
2. Observe the pixels counter.

**Expected result**
* The pixels counter should properly display the values like "a x b".

**Actual result**
* The "x" from the pixels counter is no longer displayed between the 2 px values. Please see the attached screenshot.

**Regression range**
* Found commit message:
Bug 1883765 - Screenshots direction should match browser direction. r=sfoster,Itiel

* Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5969005dae85cc8ac486b2f0bdbb7454b660f252&tochange=d4fa0d22768b546122ab141619841094150382ca
Bug: Tab preview steals focus
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-04-12 16:35:44+00:00
Resolved: 2024-04-15 13:10:09+00:00

The tab hover preview steals focus whenever it appears; it seems to occur both for chrome elements (such as the address bar) or for inputs within web content.

Steps to reproduce:
1. Set `browser.tabs.cardPreview.enabled` to `true`
2. Click the address bar to focus it
3. Hover a tab

Expected result:
Focus remains in the address bar, like it does with the preference disabled, so typing inputs to the address bar.

Actual result:
Tab preview popup steals focus, so typing does not input to the address bar.
Bug: A panel with buttons on top of the site appears sometimes
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2024-04-12 23:21:38+00:00
Resolved: 2024-06-17 16:21:02+00:00

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

Steps to reproduce:

0. Initially, the browser is in a full window and I have two monitors
1.1. Drag a window from one monitor to another. It works once in a 10-15 times
OR
1.2. Either reduce and stretch the window within the same monitor
OR
1.3 With one hundred percent probability, this bug is reproduced if I drag the tab with the mouse from the general pool of tabs just a little below. So that the tab opens in full-screen mode


Actual results:

Some kind of panel opens with empty buttons, checkboxes and dropdowns. When you click on the buttons, they do nothing. However, you cannot close this window with a cross button. This has been noticed on sites like youtube, about:blank, about:config, google, facebook, reddit, instagram 

Additional info:
OS: Windows 11 23H2 OS Build 22631.3447
Display: 2560x1440
Browser language: English




Expected results:

Obviously this shouldn't happen
Bug: browser.tabs.warnOnClose not respected in Private Browsing
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-04-13 03:42:50+00:00
Resolved: 2024-04-16 12:32:20+00:00

Steps to reproduce:

1. Tick the checkbox for "Confirm before closing multiple tabs" in about:preferences (browser.tabs.warnOnClose = true in about:config)
2. Open a Private Browsing window
3. Open some tabs
4. Press Ctrl+Shift+W (easy to hit by accident instead of Ctrl+Shift+Tab)


Actual results:

All of the tabs in the Private Browsing window were closed, and the session was destroyed.

Observed on Linux running Firefox 115.9.1esr.


Expected results:

A warning should have prompted the user whether to close all tabs.