Crash in [@ nsFrameLoader::GetExtantBrowsingContext]
Categories
(Core :: DOM: Navigation, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr68 | --- | unaffected |
| firefox-esr78 | --- | unaffected |
| firefox78 | --- | unaffected |
| firefox79 | --- | disabled |
| firefox80 | --- | fixed |
People
(Reporter: gsvelto, Assigned: u608768)
References
(Regression)
Details
(Keywords: crash, regression)
Crash Data
Attachments
(1 file)
This bug is for crash report bp-6120f184-5e26-48d9-b4c1-fb2df0200710.
Top 10 frames of crashing thread:
0 XUL nsFrameLoader::GetExtantBrowsingContext dom/base/nsFrameLoader.cpp:3209
1 XUL mozilla::dom::XULFrameElement::BrowserId dom/xul/XULFrameElement.cpp:73
2 XUL mozilla::dom::XULFrameElement_Binding::get_browserId dom/bindings/XULFrameElementBinding.cpp:205
3 XUL bool mozilla::dom::binding_detail::GenericGetter<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ThrowExceptions> dom/bindings/BindingUtils.cpp:3101
4 XUL js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:576
5 XUL js::CallGetter js/src/vm/Interpreter.cpp:780
6 XUL <name omitted> js/src/vm/NativeObject.cpp:2493
7 XUL Interpret js/src/vm/Interpreter.cpp:2977
8 XUL js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:611
9 XUL js::jit::DoCallFallback js/src/jit/BaselineIC.cpp:3100
This crash seems to have started with buildid 20200709093347. A user comment mentions this happening when he closed a private browser window.
|
||
Comment 1•4 years ago
|
||
It looks like XULFrameElement::BrowserId() is missing a null check. I think this is a regression from bug 1646563. Before that patch, this binding would end up calling into GetBrowserId(), which just returned a field. But now it looks up a value on the frame loader, which apparently can be null. Maybe this is a frame element that has had UnbindFromTree() called on it or something? Kashav, can you please take a look? Thanks.
|
||
Updated•4 years ago
|
|
|
||
Comment 2•4 years ago
|
||
I looked over all of the other callers to GetExtantBrowsingContext(), and they null check the frame loader first.
It sounds like we're trying to get the BrowserId from a frame that's been unbinded. It'd be helpful to figure out where/why this is happening, since I'm not entirely sure that we should even be entering XULFrameElement::BrowserId() without a frame loader. Bug 1625027 landed on the 8th and added code that uses BrowserId.
Also note that this is a fission-only crash.
|
|
||
Updated•4 years ago
|
Pushed by kmadan@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/109313fafcb6 Null check mFrameLoader in XULFrameElement::BrowserId, r=kmag
|
||
Comment 7•4 years ago
|
||
| bugherder | ||
|
||
Updated•4 years ago
|
|
||
Comment 8•4 years ago
|
||
I just crashed with this on beta 79 without Fission enabled, by running something like this:
gBrowser.visibleTabs.map(t => t.linkedBrowser.browserId)
in the browser console, in a window with discarded tabs/browsers present (e.g. after session restore)... Doesn't look like anything is using the browserid property right now, outside of devtools, so I guess it's unlikely this will happen in normal use?
(In reply to :Gijs (he/him) from comment #8)
I guess it's unlikely this will happen in normal use?
The devtools browserId code hasn't reached beta (or release) yet, and the crash was fixed in nightly, so it shouldn't ever happen anymore (aside from manual browserId retrievals as you've demonstrated).
Description
•