Crash in [@ nsFrameLoader::EnsureBrowsingContextAttached]
Categories
(Core :: DOM: Navigation, defect)
Tracking
()
People
(Reporter: mccr8, Unassigned)
References
Details
(Keywords: crash)
Crash Data
Crash report: https://crash-stats.mozilla.org/report/index/4b96bf67-d670-45e5-a7ff-660410230504
MOZ_CRASH Reason: MOZ_DIAGNOSTIC_ASSERT(mPendingBrowsingContext->UsePrivateBrowsing() == usePrivateBrowsing)
Top 10 frames of crashing thread:
0 libxul.so nsFrameLoader::EnsureBrowsingContextAttached dom/base/nsFrameLoader.cpp:3901
1 libxul.so nsFrameLoader::TryRemoteBrowserInternal dom/base/nsFrameLoader.cpp:2635
2 libxul.so nsFrameLoader::TryRemoteBrowser dom/base/nsFrameLoader.cpp:2828
2 libxul.so nsFrameLoader::EnsureRemoteBrowser dom/base/nsFrameLoader.cpp:2555
2 libxul.so nsFrameLoader::ShowRemoteFrame dom/base/nsFrameLoader.cpp:1097
3 libxul.so nsFrameLoader::Show dom/base/nsFrameLoader.cpp:974
4 libxul.so nsSubDocumentFrame::ShowViewer layout/generic/nsSubDocumentFrame.cpp:203
5 libxul.so AsyncFrameInit::Run layout/generic/nsSubDocumentFrame.cpp:97
6 libxul.so nsContentUtils::RemoveScriptBlocker dom/base/nsContentUtils.cpp:6025
6 libxul.so nsAutoScriptBlocker::~nsAutoScriptBlocker dom/base/nsContentUtils.h:3588
A dozen crashes with this signature in the last month. They all have this exact same crash reason.
The comment on this crash is "Want to post a comment on Disqus ( in page of Konstakang ) , "Log In" button -> popup , "Forgot password" button -> crash ...".
The URL of the crash starts with https://www.google.com/recaptcha/api2/anchor?.
|
||
Comment 2•2 years ago
|
||
It looks like in all 3 cases we're creating a new pop-up window from JS - presumably through a mechanism like window.open. Somehow, the new BrowsingContext which we were given for this window, however, is not matching the private-browsing status of the window which it is embedded in. It's very hard to say what could be causing this sort of mismatch. It could be that we are targeting the window open incorrectly.
My current best bet without any ability to double-check or reproduce this is that we appear to fall-back to trying to open a new tab in the most recent non-private-browsing window we somehow can't find the parent window which called window.open: https://searchfox.org/mozilla-central/rev/85b4f7363292b272eb9b606e00de2c37a6be73f0/dom/ipc/ContentParent.cpp#5630. Theoretically if this happened when we are trying to open a new pop-up from a private browsing window, this could theoretically lead to an issue similar to this one, where we try to open a private-browsing BC pop-up in a non-PB window, leading to this assertion failure.
In the case where the load is for a private browsing context and we don't have a parent window, the best bet might be to fall back to opening a popup window, rather than trying to find a private browsing window to open into. I don't know how we'd know if we improved the situation or fixed things though, as I don't know how we ended up in this situation :-/
|
Reporter | |
Updated•2 years ago
|
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
|
||
Updated•8 months ago
|
Description
•