av9ash/GitBugs huggingface dataset:
Bug: Unable to login to Sonicwall on M1 chip
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-02-09 13:57:29+00:00
Resolved: 2021-03-03 13:19:44+00:00

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

Steps to reproduce:

Login to any Sonicwall firewall appliance on M1 chip Mac Mini.


Actual results:

After entering username and password to login to a Sonicwall firewall appliance, URL shows https://ip-address/postlogincheck.html and stays blank.


Expected results:

Login to UI.
Bug: Unable to visit https://mozilla.slack.com/
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-02-09 14:44:41+00:00
Resolved: 2021-02-11 16:35:09+00:00

Opening a new tab for "https://mozilla.slack.com" I'm seeing no indication whatsoever of it being loaded. The page is blank, the navigation buttons are grayed out, and it seems totally broken.

If this also happens to users in the wild, they would be switching off FF. I hope it's just me.

The only log entry I see is:
> Storage access automatically granted for First-Party isolation “https://mozilla.slack.com” on “https://app.slack.com”.
Bug: webNavigation.transitionType is not being set to "auto_bookmark"
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-02-09 15:48:09+00:00
Resolved: 2021-02-15 15:47:02+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 11_1_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.146 Safari/537.36

Steps to reproduce:

Click on bookmark or entry in browser history


Actual results:

webNavigation.onCommitted listener is being passed the value "link" as its transitionType


Expected results:

webNavigation.onCommitted listener should be passed the value "auto_bookmark" as its transitionType
Bug: Firefox jumps to another Tab by itself
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-02-09 16:54:59+00:00
Resolved: 2021-07-07 15:23:52+00:00

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

Steps to reproduce:

Working in a tab while another tab is loading.




Actual results:

Firefox jumps to the loading tab by itself.

This happens in several situations if you are in tab A while in tab B is loading new content.  For example: if you work in the backend of Wordpress and you open the frontend in a new tab and jump to this frontend tab, firefox jumps back to the backend tab if in this tab still is loading content (e.g. you did save a site) (sometimes not always). Firefox changes the tab by itself too, if you rezise the whole window with several tabs.


Expected results:

Firefox should stay in the tab I'm working in.
Bug: Fix missing vcruntime140_1.dll by shipping/running redistributable installer
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2021-02-09 17:37:06+00:00
Resolved: 2024-10-01 19:42:32+00:00

I have seen three [reports of this on Reddit](https://www.google.com/search?client=firefox-b-d&q=+vcruntime140_1.dll+site%3Areddit.com%2Fr%2Ffirefox) in the past week. I'm filing this under installer even though for us it's also kind of a releng thing.

From what I can tell, `vcruntime140_1.dll` was introduced by [VC2019 Update 3](https://devblogs.microsoft.com/cppblog/making-cpp-exception-handling-smaller-x64/).

In at least [one Reddit report](https://www.reddit.com/r/firefox/comments/lbfsd0/white_border_around_window_compatibility_mode/), this issue started after they installed the VC Runtime Redistributable for the benefit of another program they were installing on their machine.

I have tried reproducing this myself, but have not yet been able to.

A few thoughts as to why this might be affecting us:

* The latest VC2019 redistributables are also shared with VC2017 and VC2015. We ship VC2017 redistributables in our bin directory, so installing the newest VC2019 version may interfere with the ones we ship;
* The dynamic linker might be preferring the newer, installed variant of the CRT DLLs when loading, but is getting confused during dependency resolution because of our local copies.
* We're probably not shipping the latest and greatest version of the CRT, missing out on bugs, security fixes, and incompatibilities such as the one in this bug.
* Shipping the CRT the way we do is not recommended by Microsoft, nor by me personally. As I have mentioned in other bugs, we really should be running the redistributable CRT installer.
Bug: Intermittent browser/components/doh/test/browser/browser_doorhangerUserReject.js | Got the expected reason. - Got "netchange", expected "startup"
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2021-02-09 21:33:06+00:00
Resolved: 2021-03-09 17:01:53+00:00

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

---
```
[task 2021-02-09T20:13:39.109Z] 20:13:39     INFO - TEST-PASS | browser/components/doh/test/browser/browser_doorhangerUserReject.js | The event records the expected decision - 
[task 2021-02-09T20:13:39.109Z] 20:13:39     INFO - Buffered messages finished
[task 2021-02-09T20:13:39.109Z] 20:13:39     INFO - TEST-UNEXPECTED-FAIL | browser/components/doh/test/browser/browser_doorhangerUserReject.js | Got the expected reason. - Got "netchange", expected "startup"
[task 2021-02-09T20:13:39.109Z] 20:13:39     INFO - Stack trace:
[task 2021-02-09T20:13:39.109Z] 20:13:39     INFO - chrome://mochikit/content/browser-test.js:test_is:1351
[task 2021-02-09T20:13:39.109Z] 20:13:39     INFO - chrome://mochitests/content/browser/browser/components/doh/test/browser/head.js:checkHeuristicsTelemetry:192
[task 2021-02-09T20:13:39.109Z] 20:13:39     INFO - TEST-PASS | browser/components/doh/test/browser/browser_doorhangerUserReject.js | Got expected provider. - ```
Bug: Popup windows opened from bookmarklets are blocked
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-02-09 22:13:52+00:00
Resolved: 2021-03-02 14:35:18+00:00

This seems to be a regression in v85. I have some bookmarklet code (the "popup" one from https://pinboard.in/howto) that opens a window to save the current page to Pinboard.in. The code is this:

javascript:q=location.href;if(document.getSelection){d=document.getSelection();}else{d='';};p=document.title;void(open('https://pinboard.in/add?url='+encodeURIComponent(q)+'&description='+encodeURIComponent(d)+'&title='+encodeURIComponent(p),'Pinboard','toolbar=no,width=700,height=350'));

Before, this used to work fine. Now, I get "Firefox prevented this site from opening a pop-up window". I have "Block pop-up windows" checked in Preferences, as it was pre-85.

IMO, popups opened from JS code in bookmarks should be allowed, because it was the user's intention to have bookmarked that JS code and trigger it.

Repro steps:
1. Create a bookmark with the code above as the "Location"
2. Navigate to a web page. Right now I'm seeing the popup blocked for https://www.mentalfloss.com/article/48795/9-little-translation-mistakes-caused-big-problems
3. Click the bookmark.
Bug: Hamburger menu icon shows update badge (green arrow) but Proton app menu doesn't have a "Restart to update" menu item
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2021-02-10 00:55:51+00:00
Resolved: 2021-04-21 15:07:38+00:00

### Steps to reproduce

1. I set `browser.proton.appmenu.enabled` pref = true and restarted Nightly.
2. Later that day, I noticed the Nightly update badge (green arrow) overlaid on the hamburger menu icon.

### Expected result

At this point, I usually open the hamburger menu and click the "Restart to update Nightly" menu item.

### Actual result

But the Photon app menu no longer includes a "Restart to update Nightly" menu item.
Bug: Intermittent TV browser/components/urlbar/tests/unit/test_resultBuckets.js | xpcshell return code: 0 | multiple groups nested maxResultCount 4 | flex nested maxResultCount 1
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2021-02-10 01:07:44+00:00
Resolved: 2021-02-15 06:21:09+00:00

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

---
```
[task 2021-02-09T22:53:20.730Z] 22:53:20     INFO -  TEST-START | browser/components/urlbar/tests/unit/test_resultBuckets.js
[task 2021-02-09T22:53:33.581Z] 22:53:33  WARNING -  TEST-UNEXPECTED-FAIL | browser/components/urlbar/tests/unit/test_resultBuckets.js | xpcshell return code: 0
[task 2021-02-09T22:53:33.581Z] 22:53:33     INFO -  TEST-INFO took 12836ms
[task 2021-02-09T22:53:33.581Z] 22:53:33     INFO -  >>>>>>>
[task 2021-02-09T22:53:33.581Z] 22:53:33     INFO -  PID 4719 | *** You are running in chaos test mode. See ChaosMode.h. ***
[task 2021-02-09T22:53:33.582Z] 22:53:33     INFO -  (xpcshell/head.js) | test MAIN run_test pending (1)
[task 2021-02-09T22:53:33.582Z] 22:53:33     INFO -  (xpcshell/head.js) | test run_next_test 0 pending (2)
[task 2021-02-09T22:53:33.582Z] 22:53:33     INFO -  (xpcshell/head.js) | test MAIN run_test finished (2)
[task 2021-02-09T22:53:33.582Z] 22:53:33     INFO -  running event loop
[task 2021-02-09T22:53:33.582Z] 22:53:33     INFO -  browser/components/urlbar/tests/unit/test_resultBuckets.js | Starting initXPCShellDependencies```
Bug: Restore session opens tabs which were already closed
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-02-10 05:13:46+00:00
Resolved: 2021-03-22 13:47:14+00:00

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

Steps to reproduce:

I simply press command Q with the following tabs open: google.com, but when I reopen it opens tabs which were previously closed with the close tab shortcut.


Actual results:

It restored the session with additional tabs which were already closed with the close tab(command-W shortcut).


Expected results:

It should restore the session to the tab state in which I pressed command-Q.
Bug: Screenshot in Zoom meeting results in blank screenshot
Status: NEW
Priority: P3
Created: 2021-02-10 08:32:18+00:00
Resolved: 2021-03-04 23:59:33+00:00

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

Steps to reproduce:

Taking a screenshot of a Zoom seminar in a Firefox browser.


Actual results:

Screenshot is black, only borders of the Zoom page are shown.


Expected results:

Screenshot should show what is actually visible (the presenter, slides etc).
Bug: Firefox 78esr Organize Bookmarks Drag-n-Drop Folders Does Not Work
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-02-10 08:39:05+00:00
Resolved: 2021-03-23 12:03:51+00:00

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

Steps to reproduce:

Firefox 78.6.1 openSUSE Linux. Opening organize bookmarks and attempting to organize folders, I attempted to move a folder shown in files-pane (right) to a new location in the folders-pane (left). Drag-n-drop did not work. No change in cursor on left-click and hold to drag was observed and the folder wasn't moved. I had to resort to archaic cut-and-paste.


Actual results:

Drag-n-drop of folders does not work in FF 78.6.1esr on Linux. Drag-n-drop of FILES does work as expected. Judging by the interface, there have been changes (Gtk+3 or 4 now) looking changes. In the past all drag-n-drop of files or folders worked. But now it does not.


Expected results:

Drag-n-drop of folders from the files-pane to a new location in the folders-pane should have worked as it always has, at least since the end of Firefox 2 (or 3) I can't recall when drag-n-drop was enabled. The drag-n-drop of FILES works, but for FOLDERS it is broken. I never realized how distasteful cut & paste had become, but in the Organize Bookmarks file-explorer interface, drag-n-drop should work for folders.
Bug: Access to recently closed tabs and windows is more difficult after recent menu change
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2021-02-10 09:07:40+00:00
Resolved: 2023-06-02 15:21:02+00:00

After Bug 1689372 the user has to navigate to the bottom of the screen to access the Recently Closed Tabs menu and then back to the top to access the most recent entry. Recent history is given a higher position in the menu despite its large size and relatively low information density. Some users already struggle with discovering recently closed windows and this change makes it harder to find.

Consideration was given to make access to recently closed tabs easier in the past (Bug 597593, Bug 1466732, Bug 1569793).
Bug: Crash in [@ OOM | large | mozalloc_abort | dogear::tree::Builder::item]
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2021-02-10 12:00:10+00:00
Resolved: 2023-11-30 00:40:31+00:00

Crash report: https://crash-stats.mozilla.org/report/index/a151b25f-f10d-4a5c-99df-485800210210

MOZ_CRASH Reason: ```MOZ_CRASH()```

Top 10 frames of crashing thread:
```
0 mozglue.dll mozalloc_abort memory/mozalloc/mozalloc_abort.cpp:33
1 mozglue.dll mozalloc_handle_oom memory/mozalloc/mozalloc_oom.cpp:51
2 xul.dll gkrust_shared::oom_hook::hook toolkit/library/rust/shared/lib.rs:134
3 xul.dll std::alloc::rust_oom ../e1884a8e3c3e813aada8254edfa120e85bf5ffca//library/std/src/alloc.rs:330
4 xul.dll alloc::alloc::__alloc_error_handler::__rg_oom ../e1884a8e3c3e813aada8254edfa120e85bf5ffca//library/alloc/src/alloc.rs:409
5 xul.dll _rust_alloc_error_handler 
6 xul.dll alloc::alloc::handle_alloc_error ../e1884a8e3c3e813aada8254edfa120e85bf5ffca//library/alloc/src/alloc.rs:363
7 xul.dll dogear::tree::Builder::item third_party/rust/dogear/src/tree.rs:260
8 xul.dll bookmark_sync::store::{{impl}}::fetch_remote_tree toolkit/components/places/bookmark_sync/src/store.rs:421
9 xul.dll bookmark_sync::merger::MergeTask::merge toolkit/components/places/bookmark_sync/src/merger.rs:210
```
Bug: [Experiment] The "Have an account? Sign in" string is not displayed on the first slide of the "about: welcome" page for the "Treatment A" and "Treatment B" branches
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-02-10 13:00:02+00:00
Resolved: 2021-02-11 13:21:43+00:00

**[Affected versions]:**
- Firefox Release 85.0.2 - Build ID: 20210208133944

**[Affected Platforms]:**
- Windows 10 x64
- Windows 7 x64
- Windows 8 x32

**[Prerequisites]:**
- Have this [user.js](https://drive.google.com/file/d/1UWcVcO6MvZh2bK2cxJBe2tAzYnn-yEj7/view?usp=sharing) saved to your PC.

**[Steps to reproduce]:**
1. Create a new profile but do not open the browser.
2. Go to the profile folder and paste the "user.js" from prerequisites.
3. Open the browser with the profile from prerequisites using the "--first-startup" argument.
4. Observe the top-right part of the "about:welcome" page's first slide.

**[Expected result]:**
- The "Have an account? Sign in" string is displayed in the top-right part of the page.
	
**[Actual result]:**
- The "Have an account? Sign in" string is not displayed at all.

**[Additional Notes]:**
- This issue is not reproducible with the experiment's "Control" branch.
- This issue is reproducible on both "Treatment A" and "Treatment B" branches.
- Attached a screenshot of the issue.

@Emily, could you please take a look over this issue?
Bug: History menu was rearranged in Nightly and now is more difficult to use
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-02-10 13:24:13+00:00
Resolved: 2025-03-02 14:51:37+00:00

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

Steps to reproduce:

I want to have quick access to recently closed tabs list. It was in submenu on top of "Show your history" button, but now it's moved to the bottom, and instead, for some unknown reason, "Clear recent history" entry is displayed on top, so I need to pay attention to not click on it accidentally.

I never used "Clear recent history" from this menu, and barely ever used "Recent History" entries from this menu - I only want easy access to list of recently closed tabs.
Bug: font on context menu is white
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-02-10 13:45:49+00:00
Resolved: 2021-02-11 10:21:38+00:00

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

Steps to reproduce:

Right click. The context menu items are of white font on a white background. Cannot see them.


Actual results:

With the last update the right click context menu appears with white font on all scenarios and themes.


Expected results:

Context menu font should differ from it's background in color.
Bug: [Proton] "Exit" keyboard shortcut is not displayed in the AppMenu/Hamburger Menu
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2021-02-10 15:48:59+00:00
Resolved: 2021-02-25 16:43:46+00:00

#### Tested with:

Nightly 87.0a1 (2021-02-10)
#### Tested on:

Windows 7
Windows 10
Ubuntu 20.04

#### Preconditions:
In about:config, set browser.proton.appmenu.enabled = true

#### Steps:

   1. Launch firefox and open the hamburger menu.
   2. Observe the Exit option.

#### Actual result:

The keyboard shortcut for the "Exit" option (Ctrl+Shift+Q) from the hamburger menu is not displayed near the "Exit" string, like for the other ones (new tab, new window,downloads, etc.), but it works, the Ctrl+Shift+Q shortcut close the browser.
#### Expected result:

The "Exit" keyboard shortcut should be displayed next to the "Exit" string. 

#### Notes:
 - The "Exit" keyboard shortcut is displayed in the regular Nightly build (without Proton pref).
 - The shortcut is displayed in the Proton UX/UI (Figma).
Bug: Firefox No Longer Works Even With Fresh Reinstall
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-02-10 16:06:47+00:00
Resolved: 2021-03-22 13:49:16+00:00

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

Steps to reproduce:

Firefox stopped opening and needed to be killed via task manager without ever opening window. 


Actual results:

After several days not using, Firefox failed to open in Windows 10. Uninstalled old version for fresh install by deleting Mozilla folder under Program Files and Mozilla Maintenance under  Program Files (x86). Tried a reinstall using Firefox Installer; Firefox Setup 85.0.1, and Firefox Setup 86 0b7. No success when clicked on icon. Bitdefender Total Security shows access in all Firewall settings for firefox.exe


Expected results:

An open window start screen for Firefox with or without error message.
Bug: Bookmarks toolbar button menu styling looks broken
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2021-02-10 22:38:02+00:00
Resolved: 2021-03-26 04:11:40+00:00

The bookmarks toolbar button menu was kind of broken by bug 1682522, because it's a menu that's styled to look like a panel and the "panel" styling wasn't updated. I think what we might want is to undo some of the new styles just for that element (by it's ID `BMB_BookmarksPopup`) so that it continues looking like a panel.
Bug: Menu/submenu positioning is misaligned
Status: RESOLVED
Priority: P1
Resolution: WORKSFORME
Created: 2021-02-10 22:38:48+00:00
Resolved: 2021-04-19 19:34:03+00:00

Since bug 1682522 affected `<select>` boxes, when a select box menu opens on the top side of the box (as happens when the box is too close to the bottom of the screen), the menu appears too far above the box, because of the space being left for the shadow. Perhaps the shadow should be removed for select boxes.

Also, submenus are offset from where they ought to appear for the same reason, because of the space being left for the shadow. Those probably can't disable the shadow, so they just need to be moved into place.
Bug: "helpSafeMode" button in app menu is not updated when in safe mode
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2021-02-10 22:40:08+00:00
Resolved: 2021-06-11 11:03:20+00:00

We also will need to update the app menu's string here: https://searchfox.org/mozilla-beta/source/browser/base/content/browser.js#1948-1951

This only affects beta right now, as another patch had landed to remove this button.
Bug: Clicking on a popup's box shadow should close the popup
Status: RESOLVED
Priority: P1
Resolution: WORKSFORME
Created: 2021-02-10 22:40:34+00:00
Resolved: 2021-03-19 15:23:59+00:00

As far as I can tell, clicking on the drop shadow of our current Windows context menus does not close them. That's fine for those because the drop shadow is approximately 1 pixel, but for the Proton design the shadow is a much larger target, so we should have clicks in that region close the popup.
Bug: Context menu navigation icons aren't positioned properly
Status: RESOLVED
Priority: P1
Resolution: DUPLICATE
Created: 2021-02-10 22:41:38+00:00
Resolved: 2021-03-20 00:18:23+00:00

According to the design spec, the navigation icons need to be closer to the edges (1em away, like the text and the separators). Currently they're each centered within their own boxes where each box is 1/4 of the legnth, so they're evenly spaced, which is correct, but too far away from the edges.
Bug: Improve submenu arrow indicator styling
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2021-02-10 22:42:33+00:00
Resolved: 2021-03-10 22:02:31+00:00

According to the design spec, the submenu arrow should be further from the edge (about 2em away).

Also, the size of the arrow doesn't scale up with the font size (e.g. if the OS text size is increased, the height of the menu item increases but the arrow stays the same size).
Bug: Improve context menu extension icon styling
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2021-02-10 22:44:10+00:00
Resolved: 2021-02-26 16:57:15+00:00

For the context menu style introduced by bug 1682522, icons for extension menu items that appear at the end of the content area context menu are vertically aligned with the text for items that don't have any icons. This may or may not be what we end up wanting.
Bug: File path is undefined for ExperimentStore
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2021-02-11 00:00:28+00:00
Resolved: 2022-01-21 17:28:34+00:00

Due to a change in the way we initialize `SharedDataMap` it looks like experiments are now being read from `undefined.json` – I think this could potentially unenroll a bunch of users across 85/86, so we probably need an uplift for this.
Bug: Experimental preferences need to define a default-value else they will be disabled by default
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2021-02-11 03:47:13+00:00
Resolved: 2021-03-11 22:02:26+00:00

In Features.toml, it is optional for a feature to have a `default-value`. When one is not specified, `false` will be used as the default. This obviously will create problems when a pref should be enabled by default. This was brought to my attention after a feature that was initially in the experimental preferences section became enabled by default but users were still getting it disabled since `default-value` was not specified.

We should explicitly define `default-value` for all features, and include an automated test that confirms that the default-value specified for the FeatureGate matches the default value in prefs.
Bug: firefox crashes with workona
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-02-11 07:08:03+00:00
Resolved: 2021-02-15 16:56:52+00:00

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

Steps to reproduce:

Using Workona with various workspace


Actual results:

Browser is consistently crashing


Expected results:

normal work