av9ash/GitBugs huggingface dataset:
Bug: shopifyspy.com - Webpage is stuck in autocomplete history
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2023-02-07 07:26:33+00:00
Resolved: 2023-02-27 10:09:16+00:00

From github: https://github.com/webcompat/web-bugs/issues/117862.

> <!-- @browser: Firefox 109.0 -->
> <!-- @ua_header: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/109.0 -->
> <!-- @reported_with: unknown -->
> 
> **URL**: http://shopifyspy.com
> 
> **Browser / Version**: Firefox 109.0
> **Operating System**: Windows 10
> **Tested Another Browser**: Yes Opera
> 
> **Problem type**: Something else
> **Description**: THIS WEBSITE IS STUCK IN MY AUTOCOMPLETE HISTORY EVEN THOUGH IVE NEVER BEEN TO IT. IVE REINSTALLED FIREFOX MULTIPLE TIMES AND ITS STILL HERE!!!!!!!!!!!!!!!!!!!!!!!!!
> **Steps to Reproduce**:
> WEBSITE I DONT USE STUCK IN HISTORY/AUTOCOMPLETE. FORCING ME TO GOTO THAT WEBSITE WHEN I DONT WANT TO. NO IDEA HOW IT EVEN GOT STUCK THERE
> <details>
>       <summary>View the screenshot</summary>
>       <img alt="Screenshot" src="https://webcompat.com/uploads/2023/2/dc3fee9b-bf35-49c6-81a0-e7a142085d9a.jpeg">
>       </details>
> 
> <details>
> <summary>Browser Configuration</summary>
> <ul>
>   <li>None</li>
> </ul>
> </details>
> 
> _From [webcompat.com](https://webcompat.com/) with ❤️_

Change performed by the [Move to Bugzilla add-on](https://addons.mozilla.org/en-US/firefox/addon/move-to-bugzilla/).
Bug: Broken text selection and highlighting in pdf.js
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-02-07 08:23:56+00:00
Resolved: 2023-03-07 10:13:08+00:00

[Tracking Requested - why for this release]: Broken text selection and highlighting.

Link to PDF file: https://www.africau.edu/images/default/sample.pdf

Steps to reproduce the problem:
1. Open https://www.africau.edu/images/default/sample.pdf
2. Select text with mouse drag e.g from `C` to `d` of `Continued` at the last sentence.
3. Copy
4. Paste other application etc.

OR
2. Double-click on a word e.g. `Continued`
3. Observe highlight 
4. Copy
5. Paste other application etc.

What is the expected behavior? (add screenshot)
Selection highlighting should be the letter of the mouse position


What went wrong? (add screenshot)
- Selected text is wrong 
- Selection highlighting is shifted.
- Highlight wrong word
See attached screenshot


Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=120838b58449ab57a04eee2823ead4054efd2e05&tochange=a88ac51c349da1444db493f972ddb2133fc45776
Bug: pdf.js doesn't respect document permissions
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-02-07 10:43:42+00:00
Resolved: 2024-06-02 20:04:52+00:00

The copy and print permission are still ignored

+++ This bug was initially created as a clone of Bug #792816 +++

This pdf restricts copying of text:
http://www.sstb.se/Homepage/Download-File/f/161759/h/6bc6229975f4c76695ee17246c645a86/Engelsk+svensk+ordlista%2C+version+2.1

Chrome and Adobe Reader respects this, but copying text is possible in pdf.js

(If you are promted to download it rather than are able to open it directly, open it from your local disk)
Ex: https://h24-files.s3.amazonaws.com/65073/161759-FDUyc.pdf
works properly in chrome
Bug: The AwesomeBar result menu button is improperly displayed in High Contrast Mode
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-02-07 12:38:14+00:00
Resolved: 2023-02-15 16:43:39+00:00

**Found in**
* 111.0a1(20230207043534)

**Affected versions**
* 111.0a1(20230207043534)

**Tested platforms**
* Affected platforms: macOS 10.15, macOS 11, macOS 12, macOS 13, Windows11, Windows 10 and Ubuntu 22
* Unaffected platforms: none

**Preconditions**
* Have High contrast mode activated:
For macOS -> Go to System preferences -> Accessibility -> Display -> Activate Invert Colours and Increase Contrast
For Windows and Ubuntu -> Accessibility -> High Contrast.
* Generate website traffic in order to have browser history.

**Steps to reproduce**
1. Activate High Contrast at OS level (how to in preconditions).
2. Launch FF.
3. Input the first several letters from a website that is in history.
4. Navigate to the specific entry.

**Expected result**
* The AwesomeBar context menu button is properly displayed in High Contrast mode.

**Actual result**
* The AwesomeBar context menu button is not properly displayed in High Contrast mode and the suspension dots are missing upon hover/keyboard selection.

**Other Notes**
* The issue occurs on Windows 11 for all the new High Contrast modes(Aquatic, Dessert, Dusk and Nightsky) with the mention that the suspension dots are just a  little more obvious in Aquatic.
Bug: Remove useless loadURI wrapper from browser.js
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2023-02-07 14:18:33+00:00
Resolved: 2023-02-07 21:46:27+00:00

I found this in bug 1810141 and removing it is easy - easier than some of the issues bug 1810141 is raising - and I already have an r+ patch, so I'm rejigging the stack so I can land this change immediately, and separately.
Bug: Firefox developer edition sometimes resets my cookies data randomly
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2023-02-07 14:46:19+00:00
Resolved: 2023-02-23 11:49:11+00:00

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

Steps to reproduce:

The bug randomly occurs or sometimes it happens when i clear my history (instead of cookies), 
please navigate this issue and fix it.


Actual results:

My cookies are being reset, that's as simple as it gets.


Expected results:

My cookies should not be reset unless i clear them but in this case i'm not clearing my cookies manually, it just happens randomly.
Bug: [Experiment] The “expose” event is not registered on the treatment branches of the "Test Window modal vs Tab modal on about:welcome" experiment
Status: NEW
Priority: P3
Created: 2023-02-07 15:07:44+00:00
Resolved: 2023-02-13 17:01:24+00:00

**[Affected versions]:**
- Firefox Release candidate 110.0 (Build ID: 20230206190557)

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

**[Prerequisites]:**
- Have the latest version of Firefox Beta 110 installed.
- Have the Firefox browser pinned to Taskbar.
- Have the [user.js](https://drive.google.com/file/d/1rE_QlyzmNhqL598EWgoOA5Y4HsJEHamk/view?usp=share_link) file saved to your PC.


**[Steps to reproduce]:**
1. Create a new Firefox profile but do not open it.
2. Navigate to the Firefox profile folder and paste the user.js file from the prerequisites.
3. Open the browser using the previously created profile and the “--first-startup” syntax.
4. Make sure that the window modal is shown.
5. Navigate to the “about:telemetry#events” page and search for the “expose” event.

**[Expected result]:**
- The “expose” event is displayed.

**[Actual result]:**
- No “expose” event is registered.

**[Notes]:**
- This issue is not reproducible on the Control branch of the experiment.
Bug: Fields filled by PDF.js aren't consistently displayed in other PDF viewers.
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2023-02-07 16:22:24+00:00
Resolved: 2023-03-06 14:00:51+00:00

Attach (recommended) or Link to PDF file here:

Steps to reproduce the problem:
1. Open the attached PDF in Firefox. See that it has some data
2. Open the PDF in some other PDF viewers.

What is the expected behavior?

Data shows

What went wrong?

In Chromium and Evince, text fields show only when focused. In Adobe PDF Viewer they don't show at all, I don't think (that's what my brother who was filing the PDF told me).
Bug: Full Screen - Window Dragging - Problem Area (Not Working)
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-02-07 16:52:18+00:00
Resolved: 2023-02-15 13:36:06+00:00

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

Steps to reproduce:

Windows 11 (22621.1194) and Firefox 109.0.1

After maximizing Firefox, I am not always able to drag the window around using the area between [Open Tabs Down Arrow] and [Title Bar - Minimize Button].  Dragging around using the areas to the left and right of the [Address Bar] works fine every time.


Actual results:

Firefox window isn't always able to move around in the above described area (to the right of all open tabs).  The problem area is the [Firefox - Window Arrangement Pop-Out].


Expected results:

I should be able to move the window around in the described problem area every time.
Bug: JS error: can't access property "suggestion", lazy.QuickSuggest.weather is undefined
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2023-02-07 17:26:05+00:00
Resolved: 2023-02-08 09:55:07+00:00

There's a JS error in the new UrlbarProviderWeather when running unrelated xpcshell tests:

```
[task 2023-02-07T15:02:37.531Z] 15:02:37     INFO -  PID 24521 | console.error: (new TypeError("can't access property \\"suggestion\\", lazy.QuickSuggest.weather is undefined", "resource:///modules/UrlbarProviderWeather.sys.mjs", 201))
```

It's logged multiple times when running for example:

```
./mach test browser/components/urlbar/tests/unit/test_providerOmnibox.js
```
Bug: Regression: Swipe-to-navigation indicator looks kind of inverted
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2023-02-07 17:28:45+00:00
Resolved: 2023-02-08 10:34:27+00:00

Nightly 111.0a1 (2023-02-07) (64-Bit)
macOS 10.15.7

1.) Take a look at the Swipe-to-navigation indicator

Actual: It looks kind of inverted.

Expected: Normal and nice looking indicator

This seems to be a recent regression.

A demo is attached.
Bug: Tab chooser skips to loaded tab, even though other tab was chosen
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2023-02-07 17:40:49+00:00
Resolved: 2023-02-23 22:12:00+00:00

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

Steps to reproduce:

I open a link on a Website in new tab. While the website loads I go to a previous tab, an easy way to circumvent long tab loading times.


Actual results:

The "tab chooser" (Tab in focus) jumps back to the now loaded tab, when it has finished loading. It seems to occur when there is only a small timespan between switching to the previous tab and the next tab finishing to load.


Expected results:

The tab chooser should stay where I put it, a tab finishing to load should be no reason to focus on the tab anyways.
Bug: Feature Callout focus ring's border radius is tighter than the callout's
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-02-07 17:59:58+00:00
Resolved: 2023-08-09 12:43:07+00:00

The focus ring on feature callout has tighter corners than the callout itself. It's because the background of the feature callout is drawn on a different element than the focused element, and these elements have different border radii. We could just make them have the same border radius, or we could change which element can be focused.
Bug: Bookmarks menu stays visible for a while even when switching to another app
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2023-02-07 18:16:13+00:00
Resolved: 2023-06-06 19:33:46+00:00

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

Steps to reproduce:

1. Open booksmarks menu
2. Click onto another application


Actual results:

Bookmarks window shows faintly for an extra second


Expected results:

Bookmarks window should close when not active
Bug: messages with non-existing or misspelled group names silently fail to record impressions for that group
Status: NEW
Priority: P3
Created: 2023-02-07 19:20:49+00:00
Resolved: 2024-05-03 16:05:07+00:00

In the process of getting bug 1805470 verified, it became clear that if a group name in a messaging system message does not exist in the message-groups provider, adding an impression for that group silently does not happen:

https://searchfox.org/mozilla-central/rev/08362489086b10de96e7a199b267ea5504c01583/browser/components/newtab/lib/ASRouter.jsm#1357-1359

is some of the code involved. 

When this happens, we want to log something to the JS console so that whoever is working on the message/experiment/rollout can tell that there's a problem and have some clue about what debugging is needed.

A somewhat-related question (knowing the answer is not required to fix this bug, however): groups can be intentionally disabled via prefs and there is code around that treats missing/not-enabled groups as valid, but I'm not really sure what the use case for that is.  Does anyone know?
Bug: Leaving Firefox open for weeks causes new tabs fail to load
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-02-07 19:41:56+00:00
Resolved: 2023-02-08 13:26:28+00:00

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

Steps to reproduce:

Open Firefox
Leave it open for at least a week
Open a new tab and visit a page
The tab will immediately fail to load but display nothing


Actual results:

Any site visited in a new tab after leaving Firefox open for a while will immediately fail to load. Visiting sites in currently open tabs works fine.


Expected results:

Firefox should work as normal and load sites in new tabs with no issues
Bug: An Assert.fail method is used in 2 urlbar tests, but this method is not part of our Assert object
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2023-02-07 20:51:27+00:00
Resolved: 2023-02-08 09:55:22+00:00

An `Assert.fail` method currently appears in 2 tests in the urlbar component:

https://searchfox.org/mozilla-central/rev/08362489086b10de96e7a199b267ea5504c01583/browser/components/urlbar/tests/browser/browser_oneOffs_heuristicRestyle.js#141

https://searchfox.org/mozilla-central/rev/08362489086b10de96e7a199b267ea5504c01583/browser/components/urlbar/tests/ext/browser/head.js#121

The [Firefox source docs for our `Assert` module](https://firefox-source-docs.mozilla.org/testing/assert.html) state that our API is "largely identical" to the NodeJS assert module (which does [implement `assert.fail`](https://nodejs.org/api/assert.html#assertfailmessage)), however we actually don't implement our own `Assert.fail`.
Bug: Search tip "Got It" button can look focused when it's actually not
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2023-02-08 00:02:25+00:00
Resolved: 2023-02-14 15:41:14+00:00

On certain browsers, the search tip can looked focused when in fact it is not. Pressing enter/space key while it's highlighted interacts with content.

Enclosing a screenshit :Gijs provided.
Bug: Ctrl+Q warning dialog backdrop color is missing
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2023-02-08 03:52:06+00:00
Resolved: 2023-02-17 11:03:39+00:00

Steps to reproduce:
1) Navigate to about:config
2) Set `browser.warnOnQuit` to `true`
3) Do Ctrl+Q

Actual results:
Dialog backdrop color is missing

Expected results:
Dialog backdrop has color

 4:35.67 INFO: No more integration revisions, bisection finished.
 4:35.67 INFO: Last good revision: e3689ce179c16ac4d23b95e5579f20b3f4182cd2
 4:35.67 INFO: First bad revision: e1d5f292fb8342fd872717284656cd32f266f371
 4:35.67 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e3689ce179c16ac4d23b95e5579f20b3f4182cd2&tochange=e1d5f292fb8342fd872717284656cd32f266f371
Bug: Download toolbar icon progress and completion color has low contrast in dark mode
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-02-08 08:08:35+00:00
Resolved: 2023-02-20 12:44:21+00:00

The download toolbar button progress color was previously cyan in dark mode but now it is blue and has low contrast.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=25f6dcab455ce114a9be95ef4298df55758805f4&tochange=49817720177787a3698bdf2e23f081efea4e1212

Regressed by Bug 1811267.
Bug: Theme selection is not respected after restart when using Firefox Color
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-02-08 09:23:43+00:00
Resolved: 2023-02-14 13:15:22+00:00

**Notes**
* After restarting, Dark Theme is still featured as enabled in about:addons. [Please see the recording for more details](https://drive.google.com/file/d/1XyVP7AkmgCuJXEz4vfgCpGPvPMICcWTB/view?usp=sharing). 

**Found in**
* Firefox 110.0

**Affected versions**
* Firefox 110.0
* Nightly 111.0a1 

**Tested platforms**
* macOS 12/13
* Windows 10
* Ubuntu 22 

**Affected platforms**
* macOS 12/13
* Windows 10
* Ubuntu 22 

**Unaffected platforms** 
* N/A 

**Steps to reproduce**
1. Launch Firefox and install the [Firefox Color add-on](https://addons.mozilla.org/en-US/firefox/addon/firefox-color/?utm_source=addons.mozilla.org&utm_medium=referral&utm_content=search). 
2. After the add-on is installed, go to [this link](https://color.firefox.com/?theme=XQAAAAIEAQAAAAAAAABBKYhm849SCia2CaaEGccwS-xNKliFuyof_iFY4LTdRm0zbNXRVAF7ZvkTn5QQ2-t9nzLQFWnCJZz8ZZdz1_iB12Yv0bo4YMWUTnP8JSQTSSiX-u78vrjUEB9EzA9zSNccQALV3P6UBIW1LKI7JETcr7ik2qwDTLhE9HNG-qGtobFJxsSdDWb5s17qMQK996mFhFB3r1_0o4CkiAXOQv-46Bwt__7JF8A) and choose one of the Preset Themes. 
3. Go to about:addons and enable Dark Theme. 
4. Open the browser console(Ctrl+Shift+J).
5. Restart the browser(Ctrl+Alt+R) in the Browser Console.


**Expected result**
* Browser retains Dark theme after restart.

**Actual result**
* Browser switches back to the theme selected in step 2. 

**Regression rage**
* Not a recent regression, will look for one as soon as possible.
Bug: Various about: pages lack a lang attribute as they fail to hardcode one and don't use fluent, causing wrong `monospace` font and some other issues
Status: NEW
Priority: P3
Created: 2023-02-08 09:39:03+00:00
Resolved: 2023-02-14 21:16:51+00:00

Previously: Bug 1810065. Specifically,

(In reply to Daniel Holbert [:dholbert] from Bug 1810065 comment #5)
> I clicked through `about:about` and I think this is the list of affected internal pages -- these are all missing a `lang` attribute on their root element):
> 
> about:buildconfig
> about:cache
> about:checkerboard
> about:debugging
> about:studies
> about:logo  (This one is just an image-document presentation of an image, so probably fine that it lacks a lang? there's no text)
> about:sync-log (This one is really just a file:/// URL; I'm not sure if we want to impose a `lang` for those or not?)

and

(In reply to :Gijs (he/him) from Bug 1810065 comment #8)
> (In reply to Daniel Holbert [:dholbert] from Bug 1810065 comment #4)
> > So presumably we are already applying some general method to add the appropriate `lang` attribute to the root of most of our internal pages, and we just missed a few like `about:cache`.
> > 
> > Gijs, do you happen to know how/where that should happen?
> 
> I think hardcoding to whatever we're actually doing is fine as an initial step, though arguably some of these pages like about:cache/about:cache-entry should actually be localized, and if we don't already have bugs on file for that perhaps we should.
> 
> I see less value in localizing `about:checkerboard`, or some of the other entries in your list. about:studies is localized [here](https://searchfox.org/mozilla-central/rev/81fbf5597044b6811e6aa4a10f3d78e8c3080f8c/toolkit/locales/en-US/chrome/global/aboutStudies.properties) so should probably get a lang attr dependent on the current locale as well. It may or may not be easy to migrate that code to fluent. Eemeli or :flod could advise on that.
> 
> about:debugging already uses ftl files but somehow doesn't put them in the markup. That should be more straightforward to address.

Note also that there are a handful of about: pages that (deliberately) do not show up in about:about, and we should also check those.
Bug: Drag scrolling a menupopup also selects text in parent window
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-02-08 10:51:56+00:00
Resolved: 2023-02-08 13:18:40+00:00

Open about:preferences, click on font selection menu and keep mouse button pressed down. When the mouse pointer leaves the popup menu while drag selecting, text outside of the menu gets selected too (see video). This didn't happen before this regression was introduced:

```
 8:59.59 INFO: No more integration revisions, bisection finished.
 8:59.59 INFO: Last good revision: 0c989b2bcd7882a9e7106e7879ab8933c2e09071
 8:59.59 INFO: First bad revision: 47c002d3637247e71ee901f32421deaecc9d8ea3
 8:59.59 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=0c989b2bcd7882a9e7106e7879ab8933c2e09071&tochange=47c002d3637247e71ee901f32421deaecc9d8ea3
```
Bug: The High and Low temperature values from the Weather result are shifted to the right side after bringing Firefox back to its maximized size
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2023-02-08 13:03:14+00:00
Resolved: 2024-06-06 16:11:44+00:00

**[Affected versions]:**
- Firefox Nightly 111.0a1 - Build ID: 20230207214329

**[Affected Platforms]:**
- Windows 10 x64
- macOS 12.4
- Linux Ubuntu 20.04 x64

**[Prerequisites]:**
- Have Firefox en-US build installed and open.
- Have a VPN client connected to a US server (for people located outside the US).
- Have the following preferences set:
`browser.urlbar.quicksuggest.enabled` = true
`browser.urlbar.weather.featureGate` = true
`browser.urlbar.weather.zeroPrefix` = false
`devtools.chrome.enabled` = true

**[Steps to reproduce]:**
1. Open the browser from the prerequisites.
2. Open the Browser Console and paste the following snippet:
`ChromeUtils.importESModule("resource:///modules/QuickSuggest.sys.mjs")
  .QuickSuggest.remoteSettings._test_setConfig({
    weather_keywords: ["weather"],
  });`
3. Type the “weather” string inside the Address Bar.
4. Minimize Firefox until the High and Low temperature values from the Weather result are moved to a lower row.
5. Maximize Firefox and click inside the Address Bar.
6. Observe the Weather result.

**[Expected result]:**
- All the elements from the Weather result are placed correctly.

**[Actual result]:**
- The High and Low temperature values are shifted to the right side of the result.
- The bullet that separates the High and Low temperatures from the forecast description is no longer displayed.

**[Notes]:**
- I have trouble with mozregression, thus I’m not able to provide a pushlog at this moment. However, this issue was only visible after implementing Bug 1814795. On a Nightly build that still displays the Weather result via Zero-prefix panel, I am not able to reproduce the issue - tried on Nightly 111.0a1 (2023-02-06).
- Here is a screen recording of the issue: [link](https://drive.google.com/file/d/1J2DL1BbQf51llNFiXGkVDzh46Rq9ahqC/view?usp=sharing).
Bug: [Win10] ‘Pin to Taskbar’ pressed multiple times results in a white icon on taskbar.
Status: NEW
Priority: --
Created: 2023-02-08 13:19:15+00:00
Resolved: 2024-02-06 10:09:42+00:00

**Found in**
* 110.0b5 dev edition (20230124185837) 

**Affected versions**
* 110.0b5 dev edition
* 110.0b5 - beta.
* 111.0a1 - nightly

**Tested platforms**
* Affected platforms: Win10
* Unaffected platforms: Ubuntu, Mac

**Steps to reproduce:**
1. Install latest dev edition build.
2. Go to the folder where Firefox is installed.
3. Right click on firefox.exe.
4. Select ‘Pin to Taskbar’.
5. Select again ‘Pin to Taskbar’.
6. Check the Firefox icons on taskbar.

**Expected result**
* Firefox icon should be displayed displayed.

**Actual result**
* Firefox icon is displayed as a white icon on taskbar.

**Regression range**
* Issue reproduces back to 88.0b1(20210322185611)

**Additional notes**
* Issue does not reproduce on Win7.
* This is related to bug 1812538.
Bug: privacy policy is not clickable
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-02-08 17:19:58+00:00
Resolved: 2023-02-09 16:11:27+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.6.1 Safari/605.1.15

Steps to reproduce:

open Saucedemo.com 
try to click on privacy policy 


Actual results:

the line with PP is not clickable


Expected results:

the user should read PP