av9ash/GitBugs huggingface dataset:
Bug: Message impressions get cleaned up when experiments end resulting in wrongly "re-"displayed messages with targeting
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-02-28 16:06:03+00:00
Resolved: 2022-04-05 12:47:40+00:00

**[Affected Versions]:**
- Firefox Beta 98.0b9 (Build ID: 20220224185616) - en-US
- Firefox Release 96.0.3 (Build ID: 20220126154723) - en-GB
- Firefox Release 94.0.2 (Build ID: 20211119140621) - en-CA

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

**[Prerequisites]:**
- Have Firefox Release 96.0.3 installed on your computer.
- No "Pin to taskbar" spotlight was previously displayed.
- Have a Firefox profile younger than 28 days.
- Have at least a website accessed in the last 6 days.
- Firefox is not pinned to the taskbar.
- Have the `nimbus.debug` pref set to `true`.
- The Remote Settings [add-on](https://github.com/mozilla-extensions/remote-settings-devtools/releases) is installed and a Poll server was actioned using Stage-Preview. 
 
**[Steps to reproduce]:**
1. Open Firefox Release 96.0.3 and force an enrollment into a previous ECO [experiment](about:studies?optin_slug=mcoman-test-eco-spotlight-3&optin_branch=treatment-a&optin_collection=nimbus-preview).
2. Restart the browser and dismiss the experiment’s spotlight.
3. Remove the experiment from the `about:studies` page.
4. Replace the existing "times.json" file in the Profile Folder from the `about:support` page with this [file](https://drive.google.com/file/d/1b2B2seAP9ybsm9wS5RCvCVUP-6ujNlXR/view?usp=sharing).
5. Restart the browser (several times if necessary) and observe the behavior.

**[Expected results]:**
- The “Pin to taskbar” modal is not displayed. 

**[Actual results]:**
- The “Pin to taskbar” modal is displayed. 

**[Notes]:**
- The issue is also reproducible using the steps described in this [comment](https://mozilla-hub.atlassian.net/browse/QA-1395?focusedCommentId=516985).
- If the user remains enrolled in the experiment, the "Pin to taskbar" spotlight is not displayed.
- [Here](https://drive.google.com/file/d/1EhLjEPQbu7jE9E0wgUHN2aRJKk8G1Q7Y/view?usp=sharing) is a screen recording of the issue.
Bug: Intermittent browser/components/urlbar/tests/browser/browser_oneOffs.js | Uncaught exception in test - Waiting for local shortcut to become selected - timed out after 50 tries.
Status: RESOLVED
Priority: P5
Resolution: DUPLICATE
Created: 2022-02-28 23:38:26+00:00
Resolved: 2022-07-25 23:16:06+00:00

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

---
```
[task 2022-02-28T22:28:43.910Z] 22:28:43     INFO - TEST-PASS | browser/components/urlbar/tests/browser/browser_oneOffs.js | Expected placeholder l10n when search mode is active - {"args":null,"id":"urlbar-placeholder-search-mode-other-bookmarks"} deepEqual {"id":"urlbar-placeholder-search-mode-other-bookmarks","args":null} - 
[task 2022-02-28T22:28:43.910Z] 22:28:43     INFO - Buffered messages finished
[task 2022-02-28T22:28:43.911Z] 22:28:43     INFO - TEST-UNEXPECTED-FAIL | browser/components/urlbar/tests/browser/browser_oneOffs.js | Uncaught exception in test - Waiting for local shortcut to become selected - timed out after 50 tries.
[task 2022-02-28T22:28:43.911Z] 22:28:43     INFO - Leaving test bound localShortcutReturn
[task 2022-02-28T22:28:43.912Z] 22:28:43     INFO - Entering test bound localShortcutEmptySearchString
[task 2022-02-28T22:28:43.912Z] 22:28:43     INFO - TEST-PASS | browser/components/urlbar/tests/browser/browser_oneOffs.js | One-offs are visible - true == true - 
```
Bug: Intermittent browser/components/downloads/test/browser/browser_downloads_pauseResume.js | Cleanup function threw an exception - UnknownError: Unexpected error: NS_ERROR_FAILURE
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2022-03-01 01:26:41+00:00
Resolved: 2022-08-02 17:08:15+00:00

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

---
```
[task 2022-03-01T00:06:15.795Z] 00:06:15     INFO - TEST-PASS | browser/components/downloads/test/browser/browser_downloads_pauseResume.js | All downloads view did not scroll when spacebar event fired on a selected download - 
[task 2022-03-01T00:06:15.796Z] 00:06:15     INFO - Leaving test bound test_downloads_library
[task 2022-03-01T00:06:15.796Z] 00:06:15     INFO - Buffered messages logged at 00:06:15
[task 2022-03-01T00:06:15.797Z] 00:06:15     INFO - removing C:\Users\task_164608607169652\AppData\Local\Temp\dm-ui-test.file
[task 2022-03-01T00:06:15.797Z] 00:06:15     INFO - removing C:\Users\task_164608607169652\AppData\Local\Temp\dm-ui-test.file
[task 2022-03-01T00:06:15.798Z] 00:06:15     INFO - Buffered messages finished
[task 2022-03-01T00:06:15.798Z] 00:06:15     INFO - TEST-UNEXPECTED-FAIL | browser/components/downloads/test/browser/browser_downloads_pauseResume.js | Cleanup function threw an exception - UnknownError: Unexpected error: NS_ERROR_FAILURE
[task 2022-03-01T00:06:15.799Z] 00:06:15     INFO - GECKO(4952) | [GPU 6760, Compositor] WARNING: Possibly dropping task posted to updater thread: file /builds/worker/checkouts/gecko/gfx/layers/apz/src/APZUpdater.cpp:362
[task 2022-03-01T00:06:15.799Z] 00:06:15     INFO - GECKO(4952) | MEMORY STAT | vsize 1063MB | vsizeMaxContiguous 1293MB | residentFast 304MB | heapAllocated 103MB
[task 2022-03-01T00:06:15.800Z] 00:06:15     INFO - TEST-OK | browser/components/downloads/test/browser/browser_downloads_pauseResume.js | took 2420ms
```
Bug: Poor contrast for theActive tab with system dark theme on Linux
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2022-03-01 05:17:59+00:00
Resolved: 2022-04-15 08:31:24+00:00

The active tab background color has a color to close the to tabbar background color. This makes it hard to see which tab is active.

This is a regression introduced by https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=fc09cf8d7c91553b71d8e83d4118fa6be3287ac8&tochange=771fc3e75f1e6c5636f42d3c5df0091bb04ff06e

To fix both bug 1741293 and this issue, I propose that we use the previous background color value only for the active tab while keeping the new background color value for the toolbar. This solution is similar to the one implemented with the firefox dark theme.
Bug: Youtube site settings not saving
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-03-01 06:04:43+00:00
Resolved: 2022-03-03 10:40:38+00:00

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

Steps to reproduce:

I enter to YouTube, set the theme in dark mode and disable autoplay.


Actual results:

The settings works until I close Firefox.


Expected results:

When I start Firefox and go back in YouTube, it keeps the default theme and the autoplay enabled.
Bug: FIrefox downloads panel doesn't respect window scaling
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-03-01 10:11:37+00:00
Resolved: 2022-03-30 19:47:16+00:00

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

Steps to reproduce:

Download files, then click the downloads button on the toolbar. 


Actual results:

The dropdown downloads panel does NOT follow the window scaling and text is tiny on a 2560x1600 screen. Ctrl + j to open the downloads pane behaves generally well but the window title "Library" is still tiny.


Expected results:

I would expect all Firefox elements to follow the window scaling in Windows, just like the main Firefox UI does.
Bug: Sponsored content should not move pinned sites
Status: NEW
Priority: P3
Created: 2022-03-01 12:35:38+00:00
Resolved: 2022-04-13 21:29:42+00:00

On my new tab page I have a couple of sites pinned so they are always in the same place and I can quickly get to them. But whenever a sponsored site shows up it moves my pinned sites out of the way breaking my muscle memory.
Bug: Firefox 98 fails to draw a window on Linux aarch64
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2022-03-01 15:02:10+00:00
Resolved: 2022-11-04 06:09:46+00:00

I'm testing aarch64 builds of Firefox 98.0-1 (current release candidate) on a raspberry pi 4 running an Ubuntu 21.10 desktop (Wayland session). Specifically RC builds for the Ubuntu packages that will go into impish-updates (from the ubuntu-mozilla-security PPA), and the snap package in the candidate channel.
In both cases, the application consistently fails to draw a window on screen. It sometimes draws a rect for the window, but nothing else is painted.

The builds for 97.0.1-1 (deb and snap) work fine in the same environment.

This issue appears to affect only aarch64 builds, other architectures are good.

I went back and tested various beta builds, and the very first beta for 98.0 was already affected by the regression.

I am going to dig deeper to try and understand what is causing this regression.
Bug: Can't send tab to desktop
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2022-03-01 16:15:14+00:00
Resolved: 2022-09-20 07:04:44+00:00

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

Steps to reproduce:

1. Have a tab open in Firefox on Android
2. Tap share
3. Tap a desktop Firefox session


Actual results:

A pop up shows "Tab sent", but nothing happens in Firefox on desktop. The other direction works perfectly fine though.


Expected results:

The tab should open in Firefox on desktop
Bug: When "Confirm before closing multiple tabs" is active closing FF using the Taskbar Icon "close window" causes freeze requiring the use of Task Manager to stop FF
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2022-03-01 18:15:25+00:00
Resolved: 2022-07-26 16:17:29+00:00

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

Steps to reproduce:

Win 10 Pro 64 bit [Version 10.0.19044.1526]

"Confirm before closing multiple tabs" is selected
Close FF using Taskbar Icon "close window" 


Actual results:

FF freeze with Taskbar Icon flashing and "closing multiple tabs" GUI open but will not act clicks.

Require Task Manager to stop FF using "Stop Task"


Expected results:

Allow "closing multiple tabs" GUI clicks
Bug: Windows reserved filenames can be used for downloaded files
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2022-03-01 21:18:59+00:00
Resolved: 2022-05-27 13:11:34+00:00

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

Steps to reproduce:

Clicking this link in Firefox will save a file named COM1:

    <a href="data:,Hello%2C%20World%21" download="COM1">download COM1</a>

That's one of the names reserved by Windows, however: https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#file-and-directory-names

All of the other reserved names (CON, PRN, AUX, COM1-9, LPT1-9) except for NUL save. NUL fails to download. Chromium sanitizes these to names like "_COM1.txt".

(I don't know if this actually has to be fixed. There doesn't seem to be a security issue and the user can manually rename the files.)
Bug: in Library window, History view changes after opening page
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-03-02 01:39:28+00:00
Resolved: 2022-04-27 08:19:44+00:00

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

Steps to reproduce:

1. Open the History menu and select Show All History (Ctrl-Shift-H).
2. In the resulting Library window, in the left-hand pane, select History -> Today.
3. In the right-hand pane, sort by Most Recent Visit. Make sure the list has too many items to fit in the window view -- i.e., make sure the list has enough entries to require use of a scrollbar.
4. Scroll down, right-click on a random item, and select Open In New Tab.


Actual results:

1. The selected page opens in a new tab.
2. After a second or 2, once the page starts loading, it appears as a new item at the start of the Library History list.
3. The Library window view moves from its previous location to the start. (That is, if the Most Recent Visit column is sorted descending, the view moves to the top of the list; if the column is sorted ascending, the view moves to the bottom of the list.)


Expected results:

1. The selected page should open in a new tab.
2. Once the page starts loading, it should appear as a new item at the start of the Library History list.
3. The Library window view should NOT move from its previous location. A common use case is scrolling down the list and right-clicking on a few pages to reopen them. With the current behavior, after opening a page, the view jumps back to the top (or bottom). The user is forced to scroll back to the previous position in the list to reopen other pages.

Note that if the user opens some page as usual, w/o right-clicking on an item in the history list, the new page appears in the History list window, but the view does NOT change. The view only changes when the user opens a page via the right-click menu.
Bug: Transitions on stripe.com site menu are not smooth
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-03-02 08:32:09+00:00
Resolved: 2022-03-02 08:51:12+00:00

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

Steps to reproduce:

Visit stripe.com
Hover site menu items like "Products", "Use Cases", etc.


Actual results:

Transitions are not very smooth, especially the width ones. It is especially noticeable when you rapidly move your cursor across the list. 


Expected results:

The transitions should be smooth.

Profile attached
https://share.firefox.dev/3vyeL3G

This seems to be another victim of `will-change`. When I uncheck all the `will-change`s I can find in devtools and add some contain:layout instead, this becomes a LOT better. The width transitions still look pretty bad, but the actual content looks of the menus looks great.
Bug: The “documentation” button from the “AS Router Admin” devtool page wrongly redirects to the “Messaging System – Firefox Source Docs documentation” page
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2022-03-02 09:12:08+00:00
Resolved: 2022-05-04 18:54:30+00:00

**[Affected versions]:**
- Firefox Nightly 99.0a1 (Build ID: 20220301215224)
- Firefox Release Candidate 98.0 (Build ID: 20220228162945)

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

**[Prerequisites]:**
- Have the Firefox browser installed and opened.
- Have the “browser.newtabpage.activity-stream.asrouter.devtoolsEnabled” pref set to true.

**[Steps to reproduce]:**
1. Open a new tab and click the “Expand tools” button from the top right corner of the page.
2. Click the “documentation” link from the “AS Router Admin” devtool.

**[Expected result]:**
 - The “https://firefox-source-docs.mozilla.org/browser/components/newtab/content-src/asrouter/docs/debugging-docs.html ” page is opened.

**[Actual result]:**
 - The “https://firefox-source-docs.mozilla.org/browser/components/newtab/content-src/asrouter/docs/index.html ” page is opened.

**[Notes]:**
- Attached is a screen recording of the issue.
Bug: Nimbus schemas reject in-flight recipes
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2022-03-02 17:58:48+00:00
Resolved: 2022-06-21 15:22:55+00:00

We still ship some recipes with a feature key for backwards compatibility, but the schema updates in bug 1726190 do not allow this key to exist, leading to all recipes being marked as invalid. We have to update the schemas to ignore this additional property when it is present.
Bug: Intermittent browser/base/content/test/performance/browser_urlbar_search.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. -
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2022-03-03 04:51:40+00:00
Resolved: 2022-03-29 17:03:38+00:00

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

---
```
INFO - TEST-PASS | browser/base/content/test/performance/browser_urlbar_search.js | should have 0 unknown flickering areas - 
[task 2022-03-03T04:33:13.437Z] 04:33:13     INFO - Buffered messages logged at 04:33:12
[task 2022-03-03T04:33:13.437Z] 04:33:13     INFO - Leaving test bound quantumbar
[task 2022-03-03T04:33:13.437Z] 04:33:13     INFO - Buffered messages finished
[task 2022-03-03T04:33:13.437Z] 04:33:13     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/performance/browser_urlbar_search.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 2022-03-03T04:33:13.438Z] 04:33:13     INFO - GECKO(1599) | MEMORY STAT | vsize 130551332MB | residentFast 2041MB
[task 2022-03-03T04:33:13.438Z] 04:33:13     INFO - TEST-OK | browser/base/content/test/performance/browser_urlbar_search.js | took 124896ms
```
Bug: Entering an address into a new tab in one window will sometimes open a new tab in another window
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2022-03-03 19:43:42+00:00
Resolved: 2022-04-13 14:01:56+00:00

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

Steps to reproduce:

I have two main firefox windows - a personal window and a work window. The work window uses the "work container" feature of firefox so that I can be logged into the correct account when I open links.


Actual results:

Sometimes, when I open a new tab (blank, nothing in the address bar) and enter an address or a search term into the box, that new empty tab vanishes and a new tab is created in my other window. This happens most often when I am trying to open a new tab in my "work" window - I hit enter and a new "work container" tab appears in my non-work firefox window. 

I have not detected a pattern for when this happens - "sometimes" is the best I can do. It seems to happen most often in my window that is using the "work container" feature but I am not 100% sure that it never goes the other way (a non-containerized tab being inserted into the work window). 


Expected results:

The tab should stay where it was and simply resolve the contents of the navigation box.
Bug: Search Settings are no longer written to a temporary file first
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2022-03-03 22:43:11+00:00
Resolved: 2022-03-05 16:30:28+00:00

In the [switch from OS.File to IOUtils](https://hg.mozilla.org/mozilla-central/rev/6b0908a8b7deda94aa920f82d5d760cf241dae2f#l2.72) in bug 1671274 the change for the write function caused us to no longer write to a tmp file before moving that over the existing settings file.

A user has just reported that their default search engine was reset, and this was possibly related to low disk space. If we're not writing to a tmp file first, then these could be related.
Bug: Permafail [tier 2] SUMMARY: ThreadSanitizer: data race /builds/worker/checkouts/gecko/widget/headless/HeadlessCompositorWidget.cpp:31:15 in NotifyClientSizeChanged
Status: RESOLVED
Priority: P5
Resolution: DUPLICATE
Created: 2022-03-04 07:23:59+00:00
Resolved: 2023-01-04 03:22:48+00:00

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

---
```
I see the following tsan permafail on tier 2 test-linux1804-64-tsan-qr/opt-mochitest-plain-headless-fis-e10s (7, 9, 12, and 17).

https://treeherder.mozilla.org/jobs?repo=try&revision=23c4934a4a6cd7671e06c63d19b5c25b32ffc416&selectedTaskRun=Jno492D5T0az199CgqUCoQ.0

https://searchfox.org/mozilla-central/rev/7f1db1d2c556b82114b62f5aa4aa29397ad5bce4/widget/headless/HeadlessCompositorWidget.cpp#31
```
Bug: dark mode
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-03-04 07:52:27+00:00
Resolved: 2022-03-04 08:14:24+00:00

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

Steps to reproduce:

White flash when

opening a new window by moving a tab out of its window.
closing a window.
starting Firefox.


Actual results:

preventing bright flash when moving tab into a new window, or when closing a window in dark mode.


Expected results:

It would be nice if the window could be (at least) black in this case.
Bug: Discord
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2022-03-04 08:20:39+00:00
Resolved: 2022-03-04 20:04:30+00:00

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

Steps to reproduce:

We are tring to resolve discord loading timeout error.


Actual results:

Login timeout errors occures multiple times.


Expected results:

Better than previous update discord working.
Bug: Combined items (zoom controls, clipboard cut/copy/paste controls, profiler button) are misaligned inside the Overflow Menu
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2022-03-04 09:27:09+00:00
Resolved: 2022-03-23 13:30:30+00:00

**Affected versions**
- 99.0a1 (2022-03-03) 

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

**Steps to reproduce**
1. Go to Menu - More tools - Customise toolbar
2. Drag several items inside the Overflow Menu (make sure to include “Profiler” and “Edit Controls”)
3. Observe the Overflow Menu 

**Expected result**
- All items are aligned.

**Actual result:**
- “Profiler”, “Edit Controls”  are not aligned with the rest of the items.

**Regression range**
- Last good revision: 1ecdb4c33adf2064c910cbb15e66b6f066c9a5ce
- First bad revision: 41da8c4b62186e3c174278a8c97b375a00a23c2a
- Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=1ecdb4c33adf2064c910cbb15e66b6f066c9a5ce&tochange=41da8c4b62186e3c174278a8c97b375a00a23c2a
Potential regressor: [1747437](https://bugzilla.mozilla.org/show_bug.cgi?id=1747437)

**Other notes**
- The issue is more visible inside the Customise page
Bug: impossible to open whatsapp web. request firefox update
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-03-04 14:18:03+00:00
Resolved: 2022-03-06 07:01:19+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:56.0) Gecko/20100101 Firefox/56.0

Steps to reproduce:

try to open whatsapp web as usual


Actual results:

send a windows : need to update firefox to firefox 60+, (my firefox is 97.0.1)


Expected results:

opening whatsapp web