av9ash/GitBugs huggingface dataset:
Bug: No coding spaces when calling custom protocols may cause command injection
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-05-24 10:07:21+00:00
Resolved: 2023-05-23 03:28:26+00:00

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

Steps to reproduce:

In the Windows system, for example, if an application is registered with the myproto protocol, the browser can use myproto://xxx to start the program

You can refer to Microsoft documentation
https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/aa767914(v=vs.85)?redirectedfrom=MSDN

Avoid spaces, quotes, or backslashes in your URI
Quote the %1 in the registration ("%1" as written in the'alert' example registration)
However, avoidance doesn't completely solve the problem of quotes in the URI or a backslash at the end of the URI.

Usually %1 or "%1" is used, depending on the application

In the case of using %1, there is a command injection vulnerability when opening the link in firefox, because firefox does not encode spaces

<a href="myproto:xxx -somearg=cmd.exe">link</a>


Actual results:

No coding spaces, -somearg=cmd.exe is injected into the command line of the program


Expected results:

use url encode, [space] -> %20
Chrome will encode spaces, so there will be no command injection vulnerabilities
Bug: Reader View page action tooltip is "undefined"
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2021-05-24 14:01:02+00:00
Resolved: 2021-06-03 02:27:13+00:00

Hovering over the Reader View page action button in the address bar shows a tooltip with text "undefined" instead of "Toggle reader view (Ctrl+Alt+R)".

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=04e17064fb366cfecfeee3019f80b477a43b1a9d&tochange=50f0907c08deb8e37a300a4188a4fcb12a9ea3c9

Regressed by Bug 1706479.
Bug: CTRL+TAB navigation is not working when list all tabs is opened
Status: NEW
Priority: P2
Created: 2021-05-24 14:02:58+00:00
Resolved: 2023-02-24 16:09:10+00:00

**Prerequisites**
* browser.ctrlTab.sortByRecentlyUsed = true

**Affected versions**
* 88.0.1
* 89.0b15
* 90.0a1 (2021-05-24)

**Affected platforms**
* Windows 10
* Ubuntu 20 
* MacOS 10.15

**Steps to reproduce**
1. Open Firefox.
2. Open multiple tabs until the list all tabs button is visible.
3. Navigate with CTRL+TAB until the list all (nr.) tabs button and enable it.
4. Use the CTRL+TAB again.

**Expected result**
* Navigation between tabs is done using CTRL+TAB.

**Actual Result**
* Tab Preview is opened but the focus is stuck at the first tab preview.

**Additional notes**
* Please see attached link to better understand the issue. https://imgur.com/a/RkXvxiJ
Bug: [Phase 1 & Phase 2] There is an inconsistent behavior of displaying Quicksuggest results depending if the search suggestions ahead of history option is enabled or not, while the tab-to-search onboarding is displayed
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2021-05-24 14:08:40+00:00
Resolved: 2021-12-23 22:28:24+00:00

**[Notes]:**
- This issue is reproducible with several search engines, such as Google, DuckDuckGo, Bing, and Amazon.

**[Affected versions]:**
- Firefox Nightly 90.0a1 (Build ID: 20210523092307);
- Firefox Beta 89.0b15 (Build ID: 20210520185752);

**[Affected Platforms]:**
- Windows 10 x64;
- macOS 10.15.7;
- Linux Mint 20 x64;

**[Prerequisites]:**
- Have the latest Firefox Nightly installed.
- Have the following prefs set: 
- `browser.urlbar.quicksuggest.enabled` to `true`.
- `browser.urlbar.experimental.firefoxSuggestLabels.enabled` to `true`.
- `browser.urlbar.quicksuggest.showedOnboardingDialog` to `true`.
- `browser.startup.upgradeDialog.version` to `89`.
- Have the “Show search suggestions ahead of browsing history” option checked.

**[Steps to reproduce]:**
1. Open the Firefox browser with the profile from prerequisites.
2. Type “wikipedia” in the Awesomebar.
3. Click the Wikipedia Firefox Suggested result.
4. Close the Wikipedia tab and type “wikipedia” in a new tab.
5. Observe the behavior.
6. Uncheck the “Show search suggestions ahead of browsing history” option from the “about:preferences” page.
7. Type “wikipedia” in the Awesomebar.
8. Observe the behavior.

**[Expected result]:**
- Step 5 - Both the Wikipedia Firefox Suggested result and the tab-to-search onboarding **are shown** in the Address bar dropdown.
- Step 8 - Both the Wikipedia Firefox Suggested result and the tab-to-search onboarding **are shown** in the Address bar dropdown.

**[Actual result]:**
- Step 5 - The Wikipedia Firefox Suggested result **is not displayed** in the Address bar dropdown; only the tab-to-search onboarding is shown.
- Step 8 - Both the Wikipedia Firefox Suggested result and the tab-to-search onboarding **are shown** in the Address bar dropdown.

**[Additional notes]:**
- Attached a screen recording of the issue.
Bug: Favicon pixelated or missing versus Chrome
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-05-24 14:36:03+00:00
Resolved: 2021-06-15 09:11:12+00:00

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

Steps to reproduce:

When going to these pages, favicons are either crunchy/pixelated or completely missing. In Chrome, both are working just fine.

Two example pages:
* https://app-updates.agilebits.com/product_history/OPM7
* https://www.politico.com/


Actual results:

Favicons are either pixelated/crunchy or missing.


Expected results:

Favicons should work correctly.
Bug: in Windows high contrast mode the cancel button in modals invisible when tabbed to with keyboard
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-05-24 19:44:10+00:00
Resolved: 2021-05-26 21:27:53+00:00

in Windows high contrast mode the cancel button in modals invisible when tabbed to with keyboard

Steps
1. enable HCM
2. launch firefox
3. open several tabs and attempt to close firefox
4. in modal dialog, tab to cancel button

Results
Cancel text is black on black background so unreadable

Expected
Cancel text is readable

Tested in latest nightly build on Windows 10 with High Contrast Black theme enabled.
Bug: checkbox for bookmarks dialog "show editor when saving" does not get proper focus indicator in Windows high contrast mode
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2021-05-24 19:56:45+00:00
Resolved: 2023-06-02 15:21:30+00:00

When tabbing to the "Show editor when saving" checkbox in the Bookmarks panel when in WIndows High Contrast Mode, there is no focus outline.

Steps:
1. Enable Windows High Contrast Black theme (HCM)
2. Open Firefox Nightly
3. Ctrl+L to focus addressbar
4. Ctrl+tab to focus bookmark star
5. Space to activate Bookmarks panel
6. Tab 5 times to checkbox

Results: not obvious checkbox is focused because no focus indicator
Expected: a focus ring around the checkbox
Other: after some playing around with the dialog, not sure what, I was once able to get the checkbox to show a focus indicator.
Bug: "Take Screenshot" doesn't work on a dropbox.com help page (perhaps due to CSP?)
Status: NEW
Priority: P2
Created: 2021-05-24 23:01:38+00:00
Resolved: 2023-01-19 21:53:48+00:00

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

Steps to reproduce:

How to Delete all Photos from an iPhone - Dropbox Business
https://www.dropbox.com/business/resources/delete-iphone-photos


Actual results:

1.Right-click
2.select "Take Screenshot"
3.error message displayed as shown


Expected results:

No error message
Bug: Stop using the channel name to determine release
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2021-05-25 01:21:47+00:00
Resolved: 2021-08-05 04:09:27+00:00

We currently use the channel to determine if a ESR policies are allowed:

https://searchfox.org/mozilla-central/source/toolkit/components/enterprisepolicies/EnterprisePoliciesParent.jsm#459

  if (AppConstants.MOZ_UPDATE_CHANNEL != "release") {
    return true;
  }

But a lot of Linuxes use the channel "default" so they get these policies on release.
Bug: Firefox Dev Edition will resize the vertical height of tabs on websites which dynamically change the text in the tab (tab referring to the literal clickable tab at the top; not the actual page).
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-05-25 02:04:35+00:00
Resolved: 2021-09-26 17:19:41+00:00

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

Steps to reproduce:

Go to a website which dynamically changes the text inside the clickable tab (top bar tab selector). TradingView charts are good examples, sometimes happens on Twitter.


Actual results:

The vertical height of the entire tab bar will increase, then decrease, randomly. This shifts the whole web page below it even if that tab is not being viewed. Incredibly annoying.


Expected results:

Tab height should remain a constant.
Bug: fx 89 ignores win10 foreground window titlebar color setting
Status: NEW
Priority: --
Created: 2021-05-25 05:08:56+00:00
Resolved: 2021-06-03 11:56:52+00:00

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

Steps to reproduce:

start fx 89


Actual results:

foreground title bar color is light gray


Expected results:

foreground titlebars should have the win10 configured background color
Bug: Adding @ to any text on the Firefox Sync login page will automatically select the entire text
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-05-25 12:39:40+00:00
Resolved: 2021-05-28 01:51:41+00:00

[Affected versions]: 
90.0a1 (2021-05-25)

[Affected platforms]:
Platforms: Windows, Mac, Ubuntu

[Steps to reproduce]

1. Launch the Firefox browser and reach the Firefox SYNC Sign in page.
2. Add any text and then insert an @.


[Expected result]
The user should be able to add any characters without issues.

[Actual result]
Adding the @ character will select the entire text.
Clicking inside the field after adding the @ character and then deleting the @ character again will highlight the entire remaining text.
Bug: Nothing happens when selecting Pin to overflow or remove from toolbar context menu option for Pocket button if context menu was opened inside the panel
Status: NEW
Priority: P3
Created: 2021-05-25 12:54:36+00:00
Resolved: 2021-08-25 08:45:09+00:00

*Affected versions*
* 90.0a1 (20210525093431)
* 89.0 (20210524222230)


*Affected platforms*

* Windows 10x64
* macOS 11.4
* Ubuntu 18.04



*Steps to reproduce*
1. Open Firefox and Pocket menu.
2. Right-click inside the pocket menu and then right-click on the toolbar button.
3. Select Pin to overflow.

*Expected result*
* Pocket menu is closed and the button is pinned to the overflow menu.

*Actual result*
* Nothing happens (same for remove from the toolbar)

*Regression range*
* This is reproducible starting with bug 1693376 so I’m assuming that this is the regressor because Remove from pocket was working while the button was inside the address bar after following the above str.



*Notes*
* Attached a screen recording.
* This happens on the latest Nightly as well with the fixed context menu for the pocket panel.
* On macOS the pocket panel is closed after step 2 but the issue is still reproducible.
* When using Pin the first time it may be possible to work but after is not working anymore.
Bug: [win] Firefox hangs if closed from the overflow menu while the search input is opened inside
Status: NEW
Priority: P3
Created: 2021-05-25 13:22:07+00:00
Resolved: 2021-11-08 08:44:14+00:00

*Affected versions*
* 90.0a1 (20210525093431)
* 89.0 (20210524222230)
* 88.0.1 (20210504152106) 
* 78.10.1 esr (20210503134251)

*Affected platforms*

* Windows 10x64




*Steps to reproduce*
1. Open Firefox and add the Address bar to the overflow menu.
2. Type something in the address bar and click on the overflow menu.


*Expected result*
* Overflow menu is closed with the address bar.

*Actual result*
* Firefox hangs.

*Regression range*
* Will search for one ASAP.



*Notes*
* Attached a screen recording.
Bug: Search is barely visible (no visible borders) with Alpenglow theme in customize mode and overflow menu
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-05-25 13:33:27+00:00
Resolved: 2021-07-06 13:18:38+00:00

**Affected versions**
- Firefox 89.0
- Firefox 90.0a1

**Affected platforms**
- Windows 10
- macOS 10.15.7
- Ubuntu 20.04

**Steps to reproduce**
1. Launch Firefox
2. Enter customize mode and set Alpenglow theme
3. Drag search to the overflow menu

**Expected result**
- The search's borders are visible like with light and dark themes

**Actual result**
- Search has no visible borders 

**Regression range**
- Until 2021-04-29 the search icon was white when Alpenglow was selected, but from 2021-04-30 and onwards, it blended its colour with the Alpenglow theme.
* Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9bb369185b518fe8a9ce231072a023599ba6ccfe&tochange=130bfa5327532a2b188e4cc06f5e1de7183327e8
* Potential regressor: Bug 1705572 - Fix search Bar colors when it's in the toolbar overflow menu.

**Additional notes**
- The issue can be seen in the attachment
Bug: Intermittent browser/components/urlbar/tests/browser/browser_retainedResultsOnFocus.js | This test exceeded the timeout threshold. It should be rewritten or split up. If that's not possible, use requestLongerTimeout(N), but only as a last resor
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2021-05-25 13:58:05+00:00
Resolved: 2022-05-31 17:06:04+00:00

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

---
```
[task 2021-05-25T13:11:39.098Z] 13:11:39     INFO - TEST-PASS | browser/components/urlbar/tests/browser/browser_retainedResultsOnFocus.js | true == true - 
[task 2021-05-25T13:11:39.098Z] 13:11:39     INFO - TEST-PASS | browser/components/urlbar/tests/browser/browser_retainedResultsOnFocus.js | true == true - 
[task 2021-05-25T13:11:39.098Z] 13:11:39     INFO - Buffered messages logged at 13:11:38
[task 2021-05-25T13:11:39.098Z] 13:11:39     INFO - Leaving test bound test_clicks_after_autofill
[task 2021-05-25T13:11:39.098Z] 13:11:39     INFO - Buffered messages finished
[task 2021-05-25T13:11:39.099Z] 13:11:39     INFO - TEST-UNEXPECTED-FAIL | browser/components/urlbar/tests/browser/browser_retainedResultsOnFocus.js | This test exceeded the timeout threshold. It should be rewritten or split up. If that's not possible, use requestLongerTimeout(N), but only as a last resort. - 
[task 2021-05-25T13:11:39.099Z] 13:11:39     INFO - GECKO(1548) | MEMORY STAT vsizeMaxContiguous not supported in this build configuration.
```
Bug: Customize - My themes - theme circles appear pixelated and not centered
Status: RESOLVED
Priority: P3
Resolution: INVALID
Created: 2021-05-25 14:00:17+00:00
Resolved: 2021-11-29 10:01:29+00:00

**Affected versions**
* 90.0a1 (2021-05-25)

**Affected platforms**
* Win10;

**Steps to reproduce** 
1. Launch Firefox, proton prefs enabled;
2. Right click on toolbar and choose Customize Toolbar;
3. Click on Themes dropdown;

**Expected result**
* theme options properly displayed;

**Actual result**
1. for theme options the inner color-demo appears to not be centered;
2. (this might be as an enhancement, to increase density of points in circle so it's drawn more smooth);

**Regression range**
* will poke DesktopQA team for further confirmations on this part;
* if I recall right, it's visible with proton-related changes to the Themes menu(size increase);

**Additional notes**
* attached screenshot to illustrate the issue.
Bug: [Proton] One Off Area alignment issues
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2021-05-25 16:25:00+00:00
Resolved: 2021-07-02 13:10:01+00:00

Nightly 90.0a1 (2021-05-25) (64-Bit)
macOS 11.4

Issue 1.) Take a look at the position of the "This time, search with" text label.
Issue 2.) Make the window small, so that the One Off buttons move below the text label.

Actual: Text label and One Off buttons are not aligned with the favicons above.

Expected: Text label could be moved by 3 px to the left and One Off buttons could be moved 6 px to the left to be aligned with the favicons above.

Screenshots are attached.

Thanks.
Bug: Manage Cookies and Site Data dialog is not usable in narrow browser windows (under about 600-700px)
Status: NEW
Priority: P5
Created: 2021-05-25 16:31:26+00:00
Resolved: 2021-07-27 08:03:00+00:00

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

Steps to reproduce:

Set the Firefox window to 640px wide (half a 1280 wide screen, Windows tiling mode).
Open about:preferences#privacy and click the Manage Site Data button.



Actual results:

The dialog opens within the Firefox window and is cut off.


Expected results:

The dialog should open as a new window.
Bug: "Sign in" and "Not now" ignore user preferences when HCM is enabled
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-05-25 18:17:35+00:00
Resolved: 2023-06-02 15:22:30+00:00

STR:

1. in about:preferences click "color" and set the dropdown to "always"
2. Set the background color to black, and text to white, hit OK
2. View "sign in" on the landing page, and "not now" on the import page

Expected:
"Sign in" and "Not now" are rendered as links, using the link colors set in about:preferences (default blue, visited purple) and have no background styling

Actual:
"Sign in" and "Not now" are rendered as black text on a white background, ignoring the user's background, text, and link styling choices in about:preferences. 

If these are meant to be buttons instead of links, they should have more padding like the "make default" button so they don't compromise readability
Bug: Progress indicators aren't filled with HCM enabled
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2021-05-25 18:24:36+00:00
Resolved: 2023-06-02 15:21:36+00:00

STR:

1. In about:preferences click "colors" and set the dropdown to "always"
2. Set the background color to black and the text/foreground color to white, click OK
3. View the "Bring it all with you" onboarding screen

Expected:
The progress indicators at the bottom of the page are filled when progress is made and remain visible when there are more actions to be taken

Actual: 
The progress indicators are borderd only and are reduced in contrast when there are more actions to be taken.

We should use the foreground color to fill the indicator when a user is on/has completed a step, and use the foreground color as a border (with background color fill) to indicate more steps to be taken.
Bug: Buttons don't react to mouseover when HCM is enabled
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2021-05-25 18:33:41+00:00
Resolved: 2023-06-02 15:21:36+00:00

STR:

1. In about:preferences, click "color" and set the dropdown to "always", hit OK
2. Navigate to welcome page or any other onboarding page with a button 
3. Mouseover the button

Expected:
The button styling is inverted to indicate mouseover

Actual:
The button styling doesn't change

See also: (MacOS)
0. In System Preferences, navigate to "Accessibility" > "Display" > check "Increase Contrast"
1. In about:preferences, click "color" and set the dropdown to "Only with High Contrast Themes"
2. Navigate to "Make firefox your default" or any other onboarding page with a button 
3. Mouseover the button

Expected:
The button is styled with the system accent color to indicate mouseover

Actual:
The button styling doesn't change

If you navigate about:preferences with MacOS HCM on, you'll see the button styling we're aiming for. The "not now" button should be styled similarly, even though it gains underline styling on mouseover
Bug: Intermittent toolkit/components/thumbnails/test/browser_thumbnails_expiration.js | A promise chain failed to handle a rejection: Could not stat file(C:\Users\task_1621965576\AppData\Local\Temp\tmpzl4q4ody.mozrunner\thumbnails\adfbe0ea64a8e4033676c5724e
Status: RESOLVED
Priority: P5
Resolution: DUPLICATE
Created: 2021-05-25 19:12:41+00:00
Resolved: 2022-07-25 23:14:04+00:00

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

---
```
[task 2021-05-25T18:21:45.799Z] 18:21:45     INFO - TEST-PASS | toolkit/components/thumbnails/test/browser_thumbnails_expiration.js | 10 dummy thumbnails remaining - 
[task 2021-05-25T18:21:45.800Z] 18:21:45     INFO - Console message: [JavaScript Error: "Error: Could not stat file(C:\Users\task_1621965576\AppData\Local\Temp\tmpzl4q4ody.mozrunner\thumbnails\adfbe0ea64a8e4033676c5724e936c62.png) because it does not exist" {file: "resource://gre/modules/PromiseWorker.jsm" line: 106}]
[task 2021-05-25T18:21:45.800Z] 18:21:45     INFO - TEST-PASS | toolkit/components/thumbnails/test/browser_thumbnails_expiration.js | no dummy thumbnails remaining - 
[task 2021-05-25T18:21:45.801Z] 18:21:45     INFO - Buffered messages finished
[task 2021-05-25T18:21:45.802Z] 18:21:45     INFO - TEST-UNEXPECTED-FAIL | toolkit/components/thumbnails/test/browser_thumbnails_expiration.js | A promise chain failed to handle a rejection: Could not stat file(C:\Users\task_1621965576\AppData\Local\Temp\tmpzl4q4ody.mozrunner\thumbnails\adfbe0ea64a8e4033676c5724e936c62.png) because it does not exist - stack: DOMException@resource://gre/modules/PromiseWorker.jsm:106:18
[task 2021-05-25T18:21:45.802Z] 18:21:45     INFO - postMessage@resource://gre/modules/PromiseWorker.jsm:342:55
[task 2021-05-25T18:21:45.802Z] 18:21:45     INFO - Rejection date: Tue May 25 2021 18:21:45 GMT+0000 (Greenwich Mean Time) - false == true - JS frame :: resource://testing-common/PromiseTestUtils.jsm :: assertNoUncaughtRejections :: line 285
[task 2021-05-25T18:21:45.802Z] 18:21:45     INFO - Stack trace:
[task 2021-05-25T18:21:45.802Z] 18:21:45     INFO - resource://testing-common/PromiseTestUtils.jsm:assertNoUncaughtRejections:285
[task 2021-05-25T18:21:45.802Z] 18:21:45     INFO - chrome://mochikit/content/browser-test.js:Tester_execTest/<:1120
[task 2021-05-25T18:21:45.802Z] 18:21:45     INFO - Leaving test bound thumbnails_expiration
[task 2021-05-25T18:21:45.803Z] 18:21:45     INFO - GECKO(4836) | MEMORY STAT | vsize 1040MB | vsizeMaxContiguous 1293MB | residentFast 276MB | heapAllocated 87MB
[task 2021-05-25T18:21:45.803Z] 18:21:45     INFO - TEST-OK | toolkit/components/thumbnails/test/browser_thumbnails_expiration.js | took 365ms
```
Bug: Remove Firefox Monitor doorhanger notification component from desktop Firefox
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-05-25 21:57:53+00:00
Resolved: 2021-06-23 02:14:36+00:00

In bug 1696550 these notifications were turned off.

The [fxmonitor component](https://searchfox.org/mozilla-central/source/browser/components/fxmonitor) does not do anything else, so it can now just be removed. We would still alert for breached logins in about:logins without this component.