av9ash/GitBugs huggingface dataset:
Bug: The Sign in button should not be displayed on the Onboarding page when the `identity.fxaccounts.enabled` pref is set to false
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2021-05-19 13:31:06+00:00
Resolved: 2021-06-03 07:10:52+00:00

**[Affected versions]:**
- Firefox Nightly 90.0a1, Build ID 20210518213628
- Firefox Beta 89.0b13, Build ID 20210516190025

**[Affected Platforms]:**
- Windows 10
- macOS 10.15
- Linux MX 4.19

**[Prerequisites]:**
- Have a new Firefox profile.
- Have the `identity.fxaccounts.enabled` pref set to `false`.

**[Steps to reproduce]:**
1. Open the browser with the profile from prerequisites.
2. Navigate to the about:welcome page and observe the top right corner of the page.

**[Expected results]:**
- Nothing is found.

**[Actual results]:**
- The `Sign in` link button is displayed, is actionable, but the Sync service is disabled.

**[Notes]:**
- The issue is also reproducible with a policies.json file or Windows GPO.
- Attached a screenshot of the issue.
Bug: Search shortcuts enabled behavior while handing off from homepage
Status: NEW
Priority: P3
Created: 2021-05-19 14:42:07+00:00
Resolved: 2021-05-19 19:11:38+00:00

**Affected versions**
* Firefox 89 beta 14
* Nightly 90.0a1 2021-05-18

**Affected platforms**
* Win 10 64-bit
* macOS 11.4 beta

**Steps to reproduce**
1. Go to about:newtab
2. Open address bar dropdown and select a search shortcut, then enter a search string
3. Unfocus address bar
4. Start typing in the in-page search field - entered text is handed-off to address bar
 
**Expected result**
* It might be less confussing to clear Search shortcut and to start a new search.

**Actual result**
* Search mode remains open, the previously entered text is deleted and replaced by the string entered at step 4

**Regression range**
* In 88 release the handling off to address bar was not enabled (happened in bug 1699834), but switching the pref to true and performing the above steps, would enable the search mode for the default search engine (behavior changed in bug 1616700).
Bug: Session Restore Talos test fails to find top window
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-05-19 17:38:30+00:00
Resolved: 2024-07-01 16:00:54+00:00

Ocassionally in [this](https://searchfox.org/mozilla-central/rev/6b099d836c882bc155d2ef285e0ad0ab9f5038f6/testing/talos/talos/test.py#273-287) talos test, we [fail to find a top level window](https://searchfox.org/mozilla-central/rev/443f87caa5fadba920b0382e12874693d6c6133a/testing/talos/talos/startup_test/sessionrestore/addon/api.js#52-53), resulting in the test erroring out

The error was patched out in bug 1220362 but the underlying cause of the test failure still remains.
Bug: Problem playing streams when "remember history" is selected
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-05-19 20:43:07+00:00
Resolved: 2021-07-01 12:40:27+00:00

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/85.0.4183.59 Chrome/85.0.4183.59 Safari/537.36

Steps to reproduce:

Opened a page with a player connected to a stream while having "remember history" turned on.


Actual results:

The stream loaded and stoped after some seconds and kept trying to load the rest without success. Also the LIVE label wasn't present and there is a timeline as a if it was a normal (non-streaming) video. The player time was negative.

Other details:

The problem with live video streams in the system I am developing and happens only in Firefox and only in normal mode and only with remember history enalbled. The player correctly loads the stream, but after a few seconds can't continue to load and just keeps trying and trying forever.

This doesn't happen in Chrome, nor if I load the page in Private Mode, nor with normal videos. Just with live streams, just in Firefox, just in normal mode. This happens both in local development (home, remote connection) and in the corporative cloud.

It's an Angular 8/NodeJs system and the player I use is Clappr. I changed to Video.js and the problem continued. The stream is coming from a load balancer with 6 children servers, each one with an apache server who have a proxy to an icecast server that originates the stream.

[load balancer] < [6 child servers with apache server proxy] > [icecast server]

I work for a very large company that has an IPS system installed. It was the first thing I thought. But the IPS team could not find any blocked traffic. Also if it was that, why would the traffic not be blocked in private mode?

So I thought about trying to pinpoint what the exact configuration is different in private mode that does the trick and I figured out that disabling all history (not only navigation and downloads or forms) makes it work too.

Does anyone knows what exactly happens when the navigation history is disabled? Besides not saving history, does it have an impact on something else? Some type of cache, network or something like that? Anyone has any idea about how to make stream work without disabling history? I can't ask my users to disable history just to use my system.

One thing that may be relevant to the issue is that in Firefox it doesn't show LIVE label when the transmission starts. It shows a negative number. Maybe this could create some problem with the history.


Expected results:

The stream should have continued normally until the end of the transmission and the LIVE label should have apeared instead the timeline.
This doesn't happen with history turned off.
Bug: Gmail will not open on Firefox.
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-05-19 21:24:31+00:00
Resolved: 2021-06-30 13:38:37+00:00

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

Steps to reproduce:

1. Cleared cache multiple times.

2. Deleted history multiple times.

3. Restarted browser multiple times.

4. Restarted laptop  few times.

5. Disabled ad blockers.




Actual results:

Nothing happened.

Gmail will not open on Firefox if the browser is closed. Gmail won't load even after clearing the cache, restarting the laptop, restarting Firefox, disabling ad blockers etc. It's only after multiple attempts and wasting a least 30 minutes that Firefox will load Gmail. This issue does not arise with Chrome or Microsoft Edge. I've seen many people complain about this on the web, and there's still no solution from Firefox.


Expected results:

This problem shouldn't exist to begin with.
Bug: Take screenshot button is missing in context menu opened on a link element
Status: NEW
Priority: P3
Created: 2021-05-19 21:30:10+00:00
Resolved: 2022-07-27 17:45:41+00:00

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

Steps to reproduce:

Do a right click on an element, that happens to be a link.


Actual results:

There's no "Take screenshot" button in the context menu (see screencast).


Expected results:

I should be able to take a screenshot of the element.
Bug: Bookmarks, Extension, Download tabs bugs.
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-05-19 23:01:44+00:00
Resolved: 2022-01-06 13:06:59+00:00

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

Steps to reproduce:

I really didn't know the specific thing that may have caused this but what I do know is that the latest firefox update kinda broke things around.


Actual results:

The pop-up for bookmarks were gone, Download tabs are gone, Extension (more formely React Developer Tools) is also gone.




Expected results:

The pop-up would appear and the download tabs should appear and the extension should appear too
Bug: Intermittent [TV] browser/base/content/test/keyboard/browser_toolbarKeyNav.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: 2021-05-19 23:50:40+00:00
Resolved: 2021-06-15 17:04:27+00:00

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

---
```
INFO - TEST-PASS | browser/base/content/test/keyboard/browser_toolbarKeyNav.js | save-to-pocket-button focused after Tab pressed - 
[task 2021-05-19T21:47:17.925Z] 21:47:17     INFO - Listening on item library-button
[task 2021-05-19T21:47:17.925Z] 21:47:17     INFO - Got focus on item: library-button
[task 2021-05-19T21:47:17.926Z] 21:47:17     INFO - TEST-PASS | browser/base/content/test/keyboard/browser_toolbarKeyNav.js | library-button focused after ArrowRight pressed - 
[task 2021-05-19T21:47:17.926Z] 21:47:17     INFO - Leaving test bound testTabStopsAfterSearchBarAdded
[task 2021-05-19T21:47:17.926Z] 21:47:17     INFO - Buffered messages finished
[task 2021-05-19T21:47:17.926Z] 21:47:17     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/keyboard/browser_toolbarKeyNav.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-19T21:47:17.926Z] 21:47:17     INFO - GECKO(2009) | MEMORY STAT vsizeMaxContiguous not supported in this build configuration.
[task 2021-05-19T21:47:17.926Z] 21:47:17     INFO - GECKO(2009) | MEMORY STAT | vsize 7713MB | residentFast 303MB | heapAllocated 116MB
[task 2021-05-19T21:47:17.926Z] 21:47:17     INFO - TEST-OK | browser/base/content/test/keyboard/browser_toolbarKeyNav.js | took 47503ms
[task 2021-05-19T21:47:17.927Z] 21:47:17     INFO - checking window state
[task 2021-05-19T21:47:17.927Z] 21:47:17     INFO - TEST-START | browser/base/content/test/keyboard/browser_toolbarKeyNav.js```
Bug: Crash on specific site
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-05-20 00:53:58+00:00
Resolved: 2021-06-30 13:40:00+00:00

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

Steps to reproduce:

Go to https://www.fangraphs.com/roster-resource/depth-charts/yankees


Actual results:

The browser crashes. Everything frozen.


Expected results:

Display the site with no issue
Bug: Bookmark dropdown menus have a white background even on default dark theme on Mac
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-05-20 03:22:00+00:00
Resolved: 2024-02-05 12:41:28+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:

1. Start Firefox, ensure it is up to date.
2. Click on a bookmark folder.
3. Observe the background color of the dropdown menu.

System Details
- OS - macOS Catalina, 10.15.7
- Firefox Developer Edition - 89.0b14 (64-bit)


Actual results:

All Dropdown menus for bookmarks have a completely white background.


Expected results:

As the default dark theme is enabled, dropdown menu should have a dark background (as is the behavior in Windows 10).
Bug: Wrong FavIcon saved with Bookmark
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-05-20 14:26:01+00:00
Resolved: 2021-06-07 08:33:36+00:00

When creating a bookmark by drag-n-drop to bookmark toolbar, the wrong favicon is saved. For example, the generic "Google Drive" icon is displayed instead of the more specific spreadsheet or document icon.  This bug does not appear in release (88.0.1)

### STR:
- Open a specific gSuite document type
- Drag and drop the url padlock onto the bookmark toolbar

### Actual Results:
- toolbar favicon is the generic gDrive icon, tab favicon is the document specific icon

### Expected Results
- tab fav icon and bookmark favicon should be the same, except for sizing

***Note:** I do not consider bug 1378362 to be a duplicate, as I'm 95% sure that drag-n-drop worked correctly earlier this year.*
Bug: Prevent leaving the local DB in empty state after signature verification failure
Status: NEW
Priority: P1
Created: 2021-05-20 15:02:46+00:00
Resolved: 2024-05-31 09:03:55+00:00

According to the [synchronization process](https://firefox-source-docs.mozilla.org/services/settings/#synchronization-process), when the signature verification fails after retry, the local DB is left empty if the collection does not have any packaged dump.

Any subsequent call to `.get()` will then trigger a synchronization. But if that synchronization fails again, then an empty list is returned. 

This can lead to unexpected behaviour for consumers (eg. unlisting users from experiments).

We could make sure we don't erase the local data if the problem comes from the server.
Bug: ui.prefersReducedMotion
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-05-20 15:08:18+00:00
Resolved: 2021-05-20 15:54:21+00:00

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

Steps to reproduce:

In about:config I set ui.prefersReducedMotion to true.


Actual results:

I click the + to open a new tab and the address bar expands.




Expected results:

Opening a new tab should not expand the address bar.
Bug: Intermittent browser/components/preferences/tests/siteData/browser_siteData3.js | Should group cookies across scheme, port and origin attributes - Got "4", expected "5"
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2021-05-20 15:20:58+00:00
Resolved: 2021-06-15 17:04:35+00:00

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

---
```
[task 2021-05-20T14:41:00.590Z] 14:41:00     INFO - TEST-PASS | browser/components/preferences/tests/siteData/browser_siteData3.js | Should group sites across scheme, port and origin attributes - 
[task 2021-05-20T14:41:00.591Z] 14:41:00     INFO - TEST-PASS | browser/components/preferences/tests/siteData/browser_siteData3.js | Should group and list sites by host - 
[task 2021-05-20T14:41:00.591Z] 14:41:00     INFO - Buffered messages finished
[task 2021-05-20T14:41:00.592Z] 14:41:00     INFO - TEST-UNEXPECTED-FAIL | browser/components/preferences/tests/siteData/browser_siteData3.js | Should group cookies across scheme, port and origin attributes - Got "4", expected "5"
[task 2021-05-20T14:41:00.592Z] 14:41:00     INFO - Stack trace:
[task 2021-05-20T14:41:00.592Z] 14:41:00     INFO - chrome://mochikit/content/browser-test.js:test_is:1362
[task 2021-05-20T14:41:00.592Z] 14:41:00     INFO - chrome://mochitests/content/browser/browser/components/preferences/tests/siteData/browser_siteData3.js:test_grouping:98```
Bug: Intermittent browser/components/preferences/tests/siteData/browser_siteData.js | Should list no sites with cookies - 1 == 0 - got 1, expected 0 (operator ==)
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2021-05-20 15:37:21+00:00
Resolved: 2021-06-15 17:04:37+00:00

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

---
```
[task 2021-05-20T14:39:32.433Z] 14:39:32     INFO - TEST-PASS | browser/components/preferences/tests/siteData/browser_siteData.js | All expectedStyleSheetURLs should have been found - 
[task 2021-05-20T14:39:32.434Z] 14:39:32     INFO - TEST-PASS | browser/components/preferences/tests/siteData/browser_siteData.js | Element should not be null, when checking visibility - 
[task 2021-05-20T14:39:32.435Z] 14:39:32     INFO - TEST-PASS | browser/components/preferences/tests/siteData/browser_siteData.js | The Settings dialog should be visible - 
[task 2021-05-20T14:39:32.436Z] 14:39:32     INFO - Buffered messages finished
[task 2021-05-20T14:39:32.440Z] 14:39:32     INFO - TEST-UNEXPECTED-FAIL | browser/components/preferences/tests/siteData/browser_siteData.js | Should list no sites with cookies - 1 == 0 - got 1, expected 0 (operator ==)
[task 2021-05-20T14:39:32.440Z] 14:39:32     INFO - Stack trace:
[task 2021-05-20T14:39:32.440Z] 14:39:32     INFO - is@resource://specialpowers/SpecialPowersSandbox.jsm:90:21
[task 2021-05-20T14:39:32.440Z] 14:39:32     INFO - @chrome://mochitests/content/browser/browser/components/preferences/tests/siteData/browser_siteData.js:396:7
[task 2021-05-20T14:39:32.440Z] 14:39:32     INFO - execute@resource://specialpowers/SpecialPowersSandbox.jsm:141:12
[task 2021-05-20T14:39:32.440Z] 14:39:32     INFO - _spawnTask@resource://specialpowers/SpecialPowersChild.jsm:1604:15
[task 2021-05-20T14:39:32.440Z] 14:39:32     INFO - receiveMessage@resource://specialpowers/SpecialPowersChild.jsm:310:21
[task 2021-05-20T14:39:32.440Z] 14:39:32     INFO - Leaving test bound```
Bug: Browsing history does not display time correctly
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-05-20 21:08:06+00:00
Resolved: 2021-06-04 14:13:36+00:00

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

Steps to reproduce:

Search any page in Firefox or in LibreWolf on Linux.


Actual results:

My local time is UTC+2, but the column "Most Recent Visit" in the Library/History displays UTC time (instead of UTC+2).


Expected results:

The column "Most Recent Visit" in the Library/History should displays a correct local time (UTC+2 in my case).
Bug: Uncommon download type should have information badge on downloads button
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2021-05-20 22:38:36+00:00
Resolved: 2021-12-06 14:06:32+00:00

For an uncommon download, we currently surface the warning icon for the download's button badge https://searchfox.org/mozilla-central/rev/2f1a015b004b79f1145c81cdf86b15481a5630e2/browser/components/downloads/DownloadsCommon.jsm#1388,1392-1394, but in the downloads panel, we show the information icon.

These should be consistent. We should change this to the blue information badge detailed here: https://bugzilla.mozilla.org/show_bug.cgi?id=1709717#c0
Bug: Hang when closing overflow menu by clicking near edge of arrow button with prefers-reduced-motion
Status: NEW
Priority: P3
Created: 2021-05-21 04:35:20+00:00
Resolved: 2021-06-10 15:35:42+00:00

STR:

1. In Windows 10 Settings, under Ease of Access -> Display, turn off "Show animations in Windows" (this enabled prefer-reduced-motion)
2. From a new profile, customize the toolbar to put the Pocket icon in the overflow menu.
3. Click the >> button to open the overflow menu
4. Move the mouse cursor to the right edge of the button, past the highlight but before the next button (the hamburger menu) becomes highlighted
5. Click

The window stops responding. See attachment.

This does not reproduce if I turn the OS-level animation preference back on.

Crash via [crashfirefox-intentionally](https://github.com/bsmedberg/crashfirefox-intentionally): https://crash-stats.mozilla.org/report/index/f87fa528-4180-4d40-8525-465930210521

When I attach a debugger it seems to be running, common stacks are:

* `mozilla::dom::EventTarget::AddEventListener` for a popupshowing event
* `mozilla::dom::Document::FlushPendingNotifications`
  * `nsIContent::GetPrimaryFrame`
  * `nsXULElement::HasMenu`
  * `mozilla::dom::XULElement_Binding::hasMenu`
* also for `mozilla::PresShell::FlushPendingNotifications`
  * `nsXULPopupManager::GetPopupFrameForContent`
  * `nsXULPopupManager::ShowPopup`
  * `mozilla::dom::XULPopupElement::OpenPopup`

So it seems like it is stuck trying to pop up the menu over and over again.

The narrowest regression range I could get was between 2020-05-13 and 2020-05-14 ([pushlog](https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=55f5d719d0359a35443d0d2586af7383645a94b6&tochange=15ffd69c83be752a28fc40a5db6b6859452fa41f)). Bug 1636057 seems the most likely immediate cause (seeing that in the pushlog is why I thought to reenable animations).

Bug 1708368 might be related as it's a hang when opening/closing the overflow menu. Bug 1633291 sounds similar for the hamburger menu, but without the hang, though I'm not able to reproduce that.
Bug: Crash in [@ OOM | small]
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-05-21 07:05:01+00:00
Resolved: 2022-06-08 21:12:33+00:00

Crash report: https://crash-stats.mozilla.org/report/index/19c5027b-de79-47e4-a364-3d7d30210520

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 mozglue.dll moz_xmalloc memory/mozalloc/mozalloc.cpp:54
3 xul.dll Pickle::WriteInt64 ipc/chromium/src/base/pickle.cc:582
4 xul.dll mozilla::ipc::WriteIPDLParam<const mozilla::VsyncEvent&> ipc/glue/IPDLParamTraits.h:63
5 xul.dll mozilla::gfx::PVsyncBridgeChild::SendNotifyVsync ipc/ipdl/PVsyncBridgeChild.cpp:76
6 xul.dll mozilla::gfx::NotifyVsyncTask::Run gfx/ipc/VsyncBridgeChild.cpp:58
7 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1145
8 xul.dll mozilla::ipc::MessagePumpForNonMainThreads::Run ipc/glue/MessagePump.cpp:302
9 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:328
```
Bug: Does not set home page when dragging URL in address bar to home page button
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-05-21 07:14:30+00:00
Resolved: 2021-06-08 08:09:41+00:00

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

Steps to reproduce:

I opened Ubuntu.com and then highlighted the web address. i dragged the highlighted address to the home button and then when the window appears asking to set this page as Homepage I select yes. 


Actual results:

I closed the browser then reopened it and home page was blank again. 
I then went into Preferences>Home>Homepage and new window>Custom URL. I then drag the highlighted Ubuntu.com into the box then leave Preferences. I close the browser then open up a new browser and the home screen is still blank. 


Expected results:

Homepage should have held on www.ubuntu.com.
Bug: Crash in [@ nsExternalAppHandler::GetBrowsingContextId]
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-05-21 08:34:16+00:00
Resolved: 2021-05-22 03:57:26+00:00

6 Nightly crashes so far, oldest with 90.0a1 20210519083222. The crash reports have local files as current page, is bug 1555637 the regressing change?


Crash report: https://crash-stats.mozilla.org/report/index/46689c91-8de1-473b-8c37-f26750210520

Reason: ```EXCEPTION_ACCESS_VIOLATION_READ```

Top 10 frames of crashing thread:
```
0 xul.dll nsExternalAppHandler::GetBrowsingContextId 
1 xul.dll static XPCWrappedNative::CallMethod js/xpconnect/src/XPCWrappedNative.cpp:1143
2 xul.dll XPC_WN_GetterSetter js/xpconnect/src/XPCWrappedNativeJSOps.cpp:965
3 xul.dll js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:512
4 xul.dll js::NativeGetProperty js/src/vm/NativeObject.cpp:2292
5 xul.dll Interpret js/src/vm/Interpreter.cpp:2929
6 xul.dll js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:544
7 xul.dll JS::Call js/src/jsapi.cpp:2796
8 xul.dll mozilla::dom::EventHandlerNonNull::Call dom/bindings/EventHandlerBinding.cpp:279
9 xul.dll mozilla::JSEventHandler::HandleEvent dom/events/JSEventHandler.cpp:201
```