av9ash/GitBugs huggingface dataset:
Bug: Focus is trapped in "Manage Nightly settings" in sidebar
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-07-29 19:10:51+00:00
Resolved: 2024-07-29 21:38:04+00:00

STR:
1. Enable new sidebar (`sidebar.revamp`) and restart browser
2. Navigate to the "Customize sidebar" pane (F6 then tab to settings gear if the pane is not open, otherwise hitting F6 twice should focus the close button in the pane)
3. Tab navigate to the "Manage Nightly settings"
4. Press "Tab" key

Expected results:
- Focus is moved from the "Manage Nightly settings" link

Actual results:
- nothing happens.

The only way I've been able to get out of this focus trap is by activating the link so that about:preferences is opened in a new tab. Otherwise, I cannot navigate from this link.
I believe [moving the e.preventDefault() inside of the if in openFirefoxSettings will fix this.](https://searchfox.org/mozilla-central/rev/dd421ae14997e3bebb9c08634633a4a3e3edeffc/browser/components/sidebar/sidebar-customize.mjs#86-89)
Bug: Unexpected autocomplete in Address bar
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-07-30 08:17:25+00:00
Resolved: 2024-07-30 14:06:49+00:00

Started seeing this a few days ago.
Type "jan" in the address bar:

AR: the suggestion is "http://www.janbambas.cz/" which is a bookmark but one that I hardly ever visit.
ER: Till a few days back, the suggestion would have been "https://phabricator.services.mozilla.com/p/jandem/"
Bug: tabbrowser.js needs to check tabContainer.verticalMode rather than tabContainer.inVerticalTabsMode
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-07-30 09:57:36+00:00
Resolved: 2024-09-03 04:23:54+00:00

There's a mismatch in bug 1899336's patch with regards to the `verticalMode` property:

https://searchfox.org/mozilla-central/rev/e637cd67f98ed4272d13a96db9a7674689122dcb/browser/components/tabbrowser/content/tabbrowser.js#850,869
Bug: Firefox forgets order of open windows
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-07-30 10:01:46+00:00
Resolved: 2024-07-31 10:07:01+00:00

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

Steps to reproduce:

(have multiple FF windows open). Exit FF. Reopen FF.


Actual results:

The tabs are retained (and in the correct order) but the order of the windows is not retained.


Expected results:

FF should remember the order of the windows (instances).
Bug: Context menu doesn't respect the add-on permissions/prefs
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2024-07-30 10:54:43+00:00
Resolved: 2024-08-29 04:12:10+00:00

Yet another extension context menu has been implemented in Bug 1893505 but it doesn't respect the add-on permissions/preferences. Some add-ons cannot be removed (e.g. enterprise policies) and some add-ons cannot be reported (because the feature is pref'ed off).

The context menu should be adjusted accordingly, similar to what's been done here: https://searchfox.org/mozilla-central/rev/e637cd67f98ed4272d13a96db9a7674689122dcb/browser/base/content/browser.js#5485,5500-5502 - Otherwise this new sidebar context menu is inconsistent with the other menus for extensions.
Bug: The “Translate Selection to <language>” option is displayed after using the Full Page Translation option
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2024-07-30 12:31:36+00:00
Resolved: 2024-08-01 06:08:44+00:00

**[Affected versions]:**
- Firefox build version: Firefox Nightly 130.0a1, Build ID: 20240728214119

**[Affected Platforms]:**
- Windows 10 x64;
- macOS 14.5;
- Ubuntu 22.04.


**[Prerequisites]:**
- Have the Firefox build installed.
- Have the “browser.translations.select.enable” and “browser.translations.enable” prefs set to true on the “about:config” page


**[Steps to reproduce]:**
1. Open a webpage that is displayed in a different language than the browser.
2. Use the Full Page Translation to translate the entire page to a language different than the browser's (and supported by the feature).
3. Select a string of text and right-click on it.

**[Expected result]:**
- The "Translate selection to (browser language)" option is not available.

**[Actual result]:**
- The "Translate selection to (browser language)" option is available.

**[Notes]:**
- This issue is not reproducible using Firefox Beta 129 and Firefox Release 128.
- We believe that this issue represents a regression and we will perform a regression window as soon as possible.
- This issue is also reproducible while being enrolled in an experiment with the “selectTranslation” feature configuration.
- The "Translate selection to (browser language)" option is also displayed if the webpage is displayed in the same language as the browser’s language.
- Attaching a screenshot of the issue.
Bug: The "Back up your sensitive data" checkbox becomes briefly unchecked after changing the password
Status: NEW
Priority: P3
Created: 2024-07-30 13:36:03+00:00
Resolved: 2024-08-09 14:39:42+00:00

**Found in**
* latest Nightly 130.0a1

**Affected versions**
* latest Nightly 130.0a1

**Tested platforms**
* Affected platforms: Windows 11, Ubuntu 22.04 and macOS 14

**Preconditions**
* `browser.backup.preferences.ui.enabled` = true 
* `browser.backup.scheduled.idle-threshold-seconds` = 5
* `browser.backup.scheduled.enabled` = true

**Steps to reproduce**
1. Go to the backup section from "about:preferences" page.
2. Enable backup by clicking on the "Manage backup" -> "Turn on backup".
3. Click on the "Back up your sensitive data" checkbox.
4. Enter a passowrd then click on the "Trun on backup" button.
5. Click on the "Change password..." button.
6. Provide another password, then save the changes.

**Expected result**
* The "Back up your sensitive data" checkbox remains checked.

**Actual result**
* The "Back up your sensitive data" checkbox is breafly unchecked.

**Regression range**
* Not a regression.
Bug: Firefox Labs telemetry is recorded when clicking on labels/descriptions
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2024-07-30 14:35:44+00:00
Resolved: 2024-08-28 13:11:22+00:00

Since the `BrowserUsageTelemetry.sys.mjs` code is listening for `click` and `command` events to track preference changes we are over reporting changes in the Firefox Labs section. These prefs are using the `moz-checkbox` component which can be clicked without changing the pref (eg clicking on the description text) and which will emit two `click` events when the label is clicked (as is the default for HTML input + label)

We should update `_recordCommand()` to handle `moz-checkbox` more gracefully. The simplest fix may be to ignore events that don't have `event.composedTarget.localName == "input"` in this case

Similarly the browser_experimental_features_resetall.js test should be updated to be failing currently, and pass after it's fixed.

[Tracking Requested - why for this release]:
Firefox Labs is going to release in 130, and we want to have accurate telemetry
Bug: The focus order for creating a password doesn't seem quite right
Status: NEW
Priority: P3
Created: 2024-07-30 14:58:09+00:00
Resolved: 2024-08-09 14:40:32+00:00

**Found in**
* latest Nightly 130.0a1

**Affected versions**
* latest Nightly 130.0a1

**Tested platforms**
* Affected platforms: Windows 11, Ubuntu 22.04 and macOS 14

**Preconditions**
* `browser.backup.preferences.ui.enabled` = true 
* `browser.backup.scheduled.idle-threshold-seconds` = 5
* `browser.backup.scheduled.enabled` = true

**Steps to reproduce**
1. Go to the backup section from "about:preferences" page.
2. Enable backup by clicking on the "Manage backup" -> "Turn on backup".
3. Click on the "Back up your sensitive data" checkbox.
5. Click on the "Password" field.
6. Press the "Tab" key from keyboard.
 
**Expected result**
* The focus is moved to the second password filed, "Repeat password".

**Actual result**
* The focus is moved to the "create strong passwords." link inside the passwords requirements' modal.


**Regression range**
* Not a regression.

**Additional notes**
* This might not be a real bug, and the current behavior could be intentional. However, I've filed this because, as a user, I expect to be able to enter my password quickly. Focusing automatically on the second password field would help wih this. Personally, I believe the "create strong passwords" link should be the last element to receive focus.
Bug: Session Restore log files will not get updated or deleted if the browser is not restarted.
Status: NEW
Priority: P3
Created: 2024-07-30 18:44:11+00:00
Resolved: 2024-10-25 23:20:52+00:00

We currently flush log messages to disk at startup and at shutdown. This has the side-effect of only deleting the old log files (older than the value of browser.sessionstore.log.appender.file.maxErrorAge) when the browser is restarted. If it is never or only infrequently restarted, those files will persist beyond the max-age. 

Similarly, if we want to log other moments that are relevant to session restore - for example window opening and closing - these will only get flushed to disk at shut down.
Bug: "Share" entry in tab context menu doesn't get its "id" attribute
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-07-30 20:58:38+00:00
Resolved: 2024-07-30 21:44:20+00:00

Steps to reproduce:

I noticed the following issue when playing around to remove the "Share" entry in tab context menu, using "userChrome.css" customization.

See at https://searchfox.org/mozilla-central/rev/20d128ef2bcaff950172fe46eada6bc74673bd25/browser/base/content/browser.js#2841

```
let l10nID =
  menu.id == "tabContextMenu"
    ? "tab-context-share-url"
    : "menu-file-share-url";
document.l10n.setAttributes(shareURL, l10nID);
```

The 2nd argument (`l10nID`) passed to `setAttributes()` is a string, whereas it is expected to be a "name->value" object. Should probably be replaced with `shareURL.setAttribute('id', l10nID)`.


Actual results:

"Share" entry in tab context menu doesn't have "id" attribute.


Expected results:

"Share" entry in tab context menu should have an "id" attribute, with value "tab-context-share-url".
Bug: Session restore "success" files tend to accumulate in long running browser sessions (Followup to bug 1909099)
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-07-31 01:30:39+00:00
Resolved: 2024-08-02 16:52:43+00:00

(In reply to Sam Foster [:sfoster] (he/him) from comment #15)
> The default value for the max age of those log files before they get deleted is 864000 seconds, which is 10 days. That's the same value I see for that pref in both the screenshots you posted. Are any of your log files older than 10 days?  
> 
> Log files created inside the 10 day window are expected to be retained. Anything older should be removed when you start or close the browser. If you never shut down the browser or only very infrequently for updates for example, its possible they'll continue to accumulate. That is a bug I can file.
Bug: File handling/Application preference for text/* is ignored if Content-disposition:inline
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2024-07-31 02:44:05+00:00
Resolved: 2024-08-30 12:32:03+00:00

Issue:
File types registered to open with a particular application open correctly in 127.
In 128, files served with content-disposition: inline ignore this setting and render in browser instead.

Backstory:
I have the Content-Type "text/dat" registered to open with notepad to make dealing with an org-internal file easier.
These files are served with content-type: inline so that users without this registration can view them in browser if they prefer.
This morning I got FF128 and noticed these files no longer opening in notepad.

Repro steps:
1.  Install FF 127.  (I used windows sandbox to ensure a clean profile)  https://ftp.mozilla.org/pub/firefox/releases/127.0/win64/en-US/
1.  Disable auto updates.   about:preferences, "Check for updates but let you choose...",  'Discard'
1.  Enable "ask whether to open or save files" under about:preferences, Applications
1.  Visit this url (setup for demoing this issue) https://pale-universal-lady.glitch.me/attachment
1.  FF asks how to open file, choose notepad and check 'do this automatically'
1.  Reload '/attachment' :  File opens direct in notepad.
1.  Visit this url : https://pale-universal-lady.glitch.me/inline : File opens direct in notepad
1.  Update to 128  Help->About->restart
1.  Visit /attachment, file opens correctly
1.  Visit /inline, file opens in browser **This is the issue**

Only tested in Windows.
Glitch site is just a quick way to serve the same content with two different content-dispostiions.
You could view source or remix here: https://glitch.com/~pale-universal-lady
Bug: Perma browser/components/tabbrowser/test/browser/tabs/browser_tab_preview.js | Test timed out - when Gecko 130 merges to beta on 2024-08-05
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-07-31 13:50:59+00:00
Resolved: 2024-08-05 07:06:10+00:00

[Central-as-beta simulation](https://treeherder.mozilla.org/jobs?repo=try&resultStatus=success%2Cpending%2Crunning%2Ctestfailed%2Cbusted%2Cexception&revision=850a7983edb5e9f696eaa0b67fb88992d011da71&searchStr=windows%2C11%2Cx86%2C22h2%2Cwebrender%2Cdebug%2Cmochitests%2Ctest-windows11-32-2009-qr%2Fdebug-mochitest-browser-chrome%2Cbc5&selectedTaskRun=boxeT3IpQvCgjmGxyKIslg.0)

[How to run these simulations](https://wiki.mozilla.org/Sheriffing/How_To/Beta_simulations#TRUNK_AS_EARLY_BETA)

[Failure log:](https://treeherder.mozilla.org/logviewer?job_id=468653615&repo=try&lineNumber=67946)

```
[task 2024-07-31T12:19:41.147Z] 12:19:41     INFO - TEST-PASS | browser/components/tabbrowser/test/browser/tabs/browser_tab_preview.js | Panel has rolluponmousewheel=true when tabs overflow - "true" == "true" - 
[task 2024-07-31T12:19:41.148Z] 12:19:41     INFO - Leaving test bound wheelTests
[task 2024-07-31T12:19:41.149Z] 12:19:41     INFO - Entering test bound tabContentChangeTests
[task 2024-07-31T12:19:41.149Z] 12:19:41     INFO - Console message: [JavaScript Warning: "This page is in Quirks Mode. Page layout may be impacted. For Standards Mode use �<!DOCTYPE html>�." {file: "data:text/html,<html><head><title>Original Tab Title</title></head><body>Hello</body></html>" line: 0}]
[task 2024-07-31T12:19:41.150Z] 12:19:41     INFO - Buffered messages finished
[task 2024-07-31T12:19:41.150Z] 12:19:41     INFO - TEST-UNEXPECTED-FAIL | browser/components/tabbrowser/test/browser/tabs/browser_tab_preview.js | Test timed out - 
[task 2024-07-31T12:19:41.151Z] 12:19:41     INFO - GECKO(4768) | Completed ShutdownLeaks collections in process 9124
[task 2024-07-31T12:19:41.152Z] 12:19:41     INFO - TEST-START | Shutdown
```
Bug: [Experiment] No telemetry is registered after clicking the "Not now" or "X" button of the infobar
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-07-31 14:18:42+00:00
Resolved: 2024-09-13 14:14:07+00:00

**[Affected versions]:**
- Firefox Release 128.0.2 (Build ID: 20240722223746)
- Firefox RC 129.0 (Build ID: 20240729133145)
- Nightly 130.0a1 (Build ID: 20240730164742)

**[Affected Platforms]:**
- Windows 10

**[Prerequisites]:**
- Have a Firefox en-US build installed.
- Have the following prefs set:
"browser.mailto.dualPrompt" set to true
"browser.mailto.dualPrompt.onLocationChange" set to true

- Have a custom tag added in about:glean page. 
 
**[Steps to reproduce]:**
1. Open the browser using the profile from the prerequisites.
2. Navigate to a webmail page and login (eg: Gmail or Outlook).
3. Click the "Not now" or "X" button from the displayed infobar.
4. Navigate to about:glean and click on the "Apply settings and submit ping" button.
5. Navigate to "https://debug-ping-preview.firebaseapp.com/" page.
6. Click on your custom tag.
7. Observe the latest "metrics" registered.

**[Expected result]:**
- An "protocolhandler.mailto.prompt_clicked" telemetry is registered for dismissing the infobar.

**[Actual result]:**
- Only the "handler_prompt_shown" telemetry is registered, there is no telemetry for dismissing the infobar.

**[Notes]:**
- The issue is reproducible for both "Not now" and "X" buttons.
- Tested also with Gmail, and no telemetry was registered for dismissing the infobar.
- Attached is a screen recording of the issue.
Bug: Screenshots should use openOrClosedShadowRoot instead of shadowRoot
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2024-07-31 15:41:10+00:00
Resolved: 2024-08-02 09:23:09+00:00

In bug 1909926, we added the ability to hover over open `shadowRoot` elements. 
We should update to using `openOrClosedShadowRoot`
Bug: www.eventbrite.ca error - says browser is out of date
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2024-07-31 16:24:15+00:00
Resolved: 2024-08-18 09:48:45+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36

Steps to reproduce:

Tried to simply access the Eventbrite page for Canadians - www.eventbrite.ca


Actual results:

immediately received error:  Your version of Internet Explorer is not longer supported.  Please update your browser.     

I am using Firefox, not Internet Explorer... so weird.


Expected results:

Should have opened the landing page for Eventbrite.
Bug: Unpinning tabs does not move them from the pinned tabs area
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2024-07-31 17:43:48+00:00
Resolved: 2024-08-05 10:48:55+00:00

Pre-requisites: 
Flip sidebar.revamp and sidebar.verticalTabs on. 

**STRs:** 
1. Pin two tabs or more.
2. Unpin a tab. 

**Expected result**
1. The unpinned tab moves to the first position in the vertical tabs area (below a separator between pinned and regular tabs), as [per spec](https://docs.google.com/document/d/1T2MNWuekJqpHpAMtXLZQsYDYP7XCMCeR5njg-gbIoeU/edit#heading=h.v0s2c747fxsn). 

**Actual result**
1. The unpinned tab moves to the first position in the **pinned tabs** area.
2. To remove the unpinned tab from the pinned tabs are, one must close it first.
Bug: Intermittent [TV] toolkit/components/nimbus/test/unit/test_ExperimentManager_enroll.js | xpcshell return code: 0
Status: NEW
Priority: P5
Created: 2024-07-31 19:20:00+00:00
Resolved: 2024-08-05 06:04:13+00:00

**Filed by:** smolnar [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=468698431&repo=autoland
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/KfUWDbLhTVSj0RNyfAB1bA/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/KfUWDbLhTVSj0RNyfAB1bA/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1

---
```
TEST-PASS | toolkit/components/nimbus/test/unit/test_ExperimentManager_enroll.js | took 476ms
[task 2024-07-31T18:02:02.870Z] 18:02:02     INFO -  INFO | Result summary:
[task 2024-07-31T18:02:02.870Z] 18:02:02     INFO -  INFO | Passed: 10
[task 2024-07-31T18:02:02.870Z] 18:02:02     INFO -  INFO | Failed: 0
[task 2024-07-31T18:02:02.870Z] 18:02:02     INFO -  INFO | Todo: 0
[task 2024-07-31T18:02:02.870Z] 18:02:02     INFO -  INFO | Retried: 0
[task 2024-07-31T18:02:02.872Z] 18:02:02     INFO -  SUITE-END | took 5s
[task 2024-07-31T18:02:02.872Z] 18:02:02     INFO -  :::
[task 2024-07-31T18:02:02.872Z] 18:02:02     INFO -  ::: Running test verification step "2. Run each test 10 times, sequentially, in chaos mode."...
[task 2024-07-31T18:02:02.872Z] 18:02:02     INFO -  :::
[task 2024-07-31T18:02:02.872Z] 18:02:02     INFO -  Using at most 8 threads.
[task 2024-07-31T18:02:02.872Z] 18:02:02     INFO -  SUITE-START | Running 1 tests
[task 2024-07-31T18:02:02.872Z] 18:02:02     INFO -  TEST-START | toolkit/components/nimbus/test/unit/test_ExperimentManager_enroll.js
[task 2024-07-31T18:02:03.359Z] 18:02:03  WARNING -  TEST-UNEXPECTED-FAIL | toolkit/components/nimbus/test/unit/test_ExperimentManager_enroll.js | xpcshell return code: 0
[task 2024-07-31T18:02:03.359Z] 18:02:03     INFO -  TEST-INFO took 487ms
[task 2024-07-31T18:02:03.359Z] 18:02:03     INFO -  >>>>>>>
[task 2024-07-31T18:02:03.359Z] 18:02:03     INFO -  PID 5343 | *** You are running in chaos test mode. See ChaosMode.h. ***
[task 2024-07-31T18:02:03.368Z] 18:02:03     INFO -  TEST-PASS | toolkit/components/nimbus/test/unit/test_ExperimentManager_enroll.js | getTempFile - [getTempFile : 44] Sanity check the temporary file doesn't exist. - true == true
```
Bug: MSI should install into existing Firefox install directory
Status: NEW
Priority: P3
Created: 2024-07-31 19:22:37+00:00
Resolved: 2024-09-05 22:45:37+00:00

Currently if you install the Firefox 32 bit MSI and then the 64 bit MSI, they are put in separate directories.

The MSI should honor an existing Firefox install and overwrite it.

This is consistent with how other browsers work (I tried Chrome and I was told Edge does the same)
Bug: Drag-and-drop of (large amount of) text on address bar causes 7s hang on the parent process
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2024-08-01 04:11:19+00:00
Resolved: 2025-01-18 17:47:25+00:00

STR:
1. Open the attached testcase in the browser
2. Select all the text (Ctrl+A) and then drag-and-drop the selected text to the address bar

AR: The whole browser freezes (for 7 seconds)
ER: Not so

Profile: https://share.firefox.dev/3LJu4xg

Bisection:
Bug 1841869 - entering "abc @xyz.[TLD]" in address bar opens a prompt regarding loading "xyz.[TLD]" instead of searching for "abc @xyz.[TLD]" on the default search engine.r=adw

Differential Revision: https://phabricator.services.mozilla.com/D198196
Bug: Search window unresponsive, I have to close firefox to have it working.
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-08-01 04:41:08+00:00
Resolved: 2024-09-02 15:16:11+00:00

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

Steps to reproduce:

It happens from time to time, and the search area you enter anything and nothing happens.


Actual results:

When you enter a word or a sentence to search, nothing happens in that new tab. I always choose Google as the search engine.  This was my search request "how to copy photos from google photos to a disk" nothing happens in that new tab


Expected results:

Browser should have listed results but nothing happens.
Bug: [Experiment] Two infobars are displayed on "treatment-a" branch when first navigating on a webmail page that already exists in the Applications list
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-08-01 11:50:12+00:00
Resolved: 2024-09-13 14:13:34+00:00

**[Affected versions]:**
- Firefox RC 129.0 (Build ID: 20240729133145)
- Nightly 130.0a1 (Build ID: 20240730164742)

**[Affected Platforms]:**
- Windows 10
- Windows 11

**[Prerequisites]:**
- Have a Firefox en-US build installed.
- Have the following prefs set: "nimbus.debug" set to true.

**[Steps to reproduce]:**
1. Open the browser using the profile from the prerequisites.
2. In order to force enroll in the treatment-a branch, navigate to the following link: about:studies?optin_slug=improved-mailto-handling-with-os-integration&optin_branch=treatment-a&optin_collection=nimbus-preview
3. Close the tab with the link from Step 2.
4. Restart the browser.
5. Navigate to gmail.com and log in with a valid account.
6. Observe the infobar.

**[Expected result]:**
- Only one infobar is triggered.

**[Actual result]:**
- Two infobars are triggered.

**[ Notes]:**
- I have tried to find if this is a regression, but sometimes the issue is NOT reproducible on some Firefox profiles even if I follow the same steps. 
- The issue is reproducible with any webmail that is added in the Application list before enrolling in the experiment.
- The issue is also reproducible by naturally enrolling in the experiment.
- The issue is not reproducible if the prefs are manually changed without enrolling in the experiment.
- The issue is not reproducible in the "treatment-b" branch. 
- I did not manage to reproduce the issue on Firefox 128. I have tried to find a regression range but without luck. 
- In the attached screen recording I have used another method to reproduce this issue to avoid using my personal Gmail account in the video. 
- Attached is a screen recording of the issue.