1670821 - Crash in [@ nsWindowWatcher::OpenWindowInternal]

Status: NEW

(Core :: Window Management, defect)

Description

[Hiroyuki Ikezoe (:hiro)]

A STR is in bug 1661984 comment 20.

Maybe Fission related. (DOMFissionEnabled=1)

Crash report: https://crash-stats.mozilla.org/report/index/c59ee04a-cf41-4d0d-8def-4d7e20201012

MOZ_CRASH Reason: MOZ_DIAGNOSTIC_ASSERT(newBC->UseRemoteSubframes() == !!(chromeFlags & nsIWebBrowserChrome::CHROME_FISSION_WINDOW))

Top 10 frames of crashing thread:

0 XUL nsWindowWatcher::OpenWindowInternal toolkit/components/windowwatcher/nsWindowWatcher.cpp:1148
1 XUL {virtual override thunk} 
2 XUL nsGlobalWindowOuter::OpenInternal dom/base/nsGlobalWindowOuter.cpp:7275
3 XUL nsGlobalWindowOuter::OpenDialogOuter dom/base/nsGlobalWindowOuter.cpp:5906
4 XUL nsGlobalWindowInner::OpenDialog dom/base/nsGlobalWindowInner.cpp:3871
5 XUL mozilla::dom::Window_Binding::openDialog dom/bindings/WindowBinding.cpp:7264
6 XUL bool mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::MaybeCrossOriginObjectThisPolicy, mozilla::dom::binding_detail::ThrowExceptions> dom/bindings/BindingUtils.cpp:3229
7 XUL js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:601
8 XUL Interpret js/src/vm/Interpreter.cpp:3270
9 XUL js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:638

Comment 1

[Hiroyuki Ikezoe (:hiro)]

From bug 1661984 comment 21.

Actually, printing anything from a non-Fission window with Fission enabled crashes.

Nika, the assertion in question doesn't suppose the case^?

Comment 2

[Neha Kochar [:neha]]

We'll disable the non-fission window option for Fission experiment case (bug 1670966) so this crash doesn't happen for the experiment population. This will still be a problem for the voluntarily opted-in users.

Comment 3

[Nika Layzell [:nika] (ni? for response)]

This appears to be caused by the unfortunate default setting behaviour used in CalculateChromeFlagsForSystem for determining useRemoteTabs and useRemoteSubframes (https://searchfox.org/mozilla-central/rev/803b368879fa332e8e2c1840bf1ec164f7ed2c32/toolkit/components/windowwatcher/nsWindowWatcher.cpp#1876-1901). In this case, the openDialog call is actually targeting an existing window, rather than creating a new one, and the chrome flags happen to not match.

The assertions which are failing should probably be disabled unless the window is new, rather than existing. Perhaps disabling them if !windowIsNew?

Comment 4

[Chris Peterson [:cpeterson]]

Nika, I see 2000+ crash reports for this diagnostic assertion failure from 78.x ESR users. I thought MOZ_DIAGNOSTIC_ASSERT was only enabled in Nightly and DevEdition builds?? Is this assertion checked in e10s mode? I also see a few crashes from Beta users on 85 and 86 and none of them have Fission enabled.

I hit this crashes when testing a page in a non-Fission window when I had Fission enabled.

bp-1948f029-3b18-457c-85f0-c3b7e0210203

MOZ_DIAGNOSTIC_ASSERT(newBC->UseRemoteSubframes() == !!(chromeFlags & nsIWebBrowserChrome::CHROME_FISSION_WINDOW))

Comment 5

[Julien Cristau [:jcristau]]

It's not a diagnostic assert on esr78, it's MOZ_RELEASE_ASSERT(newBC->GetOpenerId() == parentBC->Id())

Comment 6

[Nika Layzell [:nika] (ni? for response)]

As :jcristau noted, this is a different assertion on esr.

Crashing when testing a page in a non-Fission window with Fission enabled is somewhat understandable, as the code for opening new windows doesn't always handle launching like this super well. Given that we don't intend to support "Open new non-fission window" in the long term, I don't think it's a super high priority to hunt down & fix these issues.

Comment 7

[Chris Peterson [:cpeterson]]

Crashes related to "New Non-Fission Window" don't need to block Fission. This test menu item will eventually be removed.

Comment 8

[Chris Peterson [:cpeterson]]

The "Open Non-Fission Window" menu item will be removed in bug 1661791, but not all of these crash reports have Fission enabled, so there are multiple causes.

Comment 9

[Wayne Mery (:wsmwk)]

Thunderbird crash rate is somewhat higher, so Thunderbird might have a unique bug.

Comment 10

[Wayne Mery (:wsmwk)]

(In reply to Wayne Mery (:wsmwk) from comment #9)

Thunderbird crash rate is somewhat higher, so Thunderbird might have a unique bug.

filed bug 1843741

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

The bug is linked to a topcrash signature, which matches the following criterion:

• Top 10 AArch64 and ARM crashes on nightly

For more information, please visit BugBot documentation.

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

Based on the topcrash criteria, the crash signature linked to this bug is not a topcrash signature anymore.

For more information, please visit BugBot documentation.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

Firefox desktop Nightly:
https://crash-stats.mozilla.org/report/index/a2875394-bfde-4085-95d7-a68650240919
MOZ_DIAGNOSTIC_ASSERT(targetBC->UsePrivateBrowsing()) (CHROME_PRIVATE_WINDOW passed, but got non-private window)

Fenix Nightly:
https://crash-stats.mozilla.org/report/index/ec74143e-49d0-4f5c-8a65-d6f730240919
MOZ_DIAGNOSTIC_ASSERT(equal) (aLoadState should contain the same URI passed to this function.)