1549998 - Crash in [@ mozilla::dom::ContentChild::ProvideWindowCommon]

Status: NEW

(Core :: DOM: Core & HTML, defect, P3)

Description

[Marcia Knous [:marcia]]

This bug is for crash report bp-5ff6bc97-b547-41a4-9a76-ee5e40190421.

Small volume crash which appears to have started in 20190419094745: https://bit.ly/2Vlb3t8. 5 crashes/6 installs all on Windows 10.

Code was touched in Bug 1542204. ni on :farre

Top 10 frames of crashing thread:

0 xul.dll mozilla::dom::ContentChild::ProvideWindowCommon dom/ipc/ContentChild.cpp:905
1 xul.dll nsresult mozilla::dom::TabChild::ProvideWindow dom/ipc/TabChild.cpp:936
2 xul.dll nsresult nsWindowWatcher::OpenWindowInternal toolkit/components/windowwatcher/nsWindowWatcher.cpp:761
3 xul.dll nsresult nsWindowWatcher::OpenWindow2 toolkit/components/windowwatcher/nsWindowWatcher.cpp:367
4 xul.dll nsGlobalWindowOuter::OpenInternal dom/base/nsGlobalWindowOuter.cpp:7202
5 xul.dll nsresult nsGlobalWindowOuter::Open dom/base/nsGlobalWindowOuter.cpp:5691
6 xul.dll nsresult nsDocShell::PerformRetargeting docshell/base/nsDocShell.cpp:8777
7 xul.dll nsresult nsDocShell::InternalLoad docshell/base/nsDocShell.cpp:9181
8 xul.dll nsresult nsDocShell::OnLinkClickSync docshell/base/nsDocShell.cpp:12728
9 xul.dll nsresult OnLinkClickEvent::Run docshell/base/nsDocShell.cpp:12438

Comment 1

[Andreas Farre [:farre]]

This is rather harmless MOZ_DIAGNOSTIC_ASSERT. I'll look into it.

Comment 2

[Kris Maglione [:kmag]]

We should only be able to reach this assertion when Fission is disabled.

Comment 3

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

Since the crash volume is low (less than 5 per week), the severity is downgraded to S3. Feel free to change it back if you think the bug is still critical.

For more information, please visit auto_nag documentation.

Comment 4

[Kris Maglione [:kmag]]

As far as I can tell, this can only happen when a frame attempts to open a "noopener" window with "_parent" as the target, when it can't access its parent frame, and fission is disabled. That's a pretty odd circumstance, and the only negative consequence is a frame crash. And when Fission comes to Android, it won't be able to happen anywhere. So I'm not worried about it.

But we could also just bail out here rather than crashing, since after reading the code, I can see that is definitely a thing that can happen.

There's also an unrelated Windows crash with the same signature, where it looks like browsingContext is an invalid pointer.

Comment 5

[Andreas Farre [:farre]]

Hsin-Yi, this is extremely rare, and Fission only. I haven't been able to work on this, so I'm unassigning. Should we re-triage this?

Comment 6

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Andreas Farre [:farre] from comment #5)

Hsin-Yi, this is extremely rare, and Fission only. I haven't been able to work on this, so I'm unassigning. Should we re-triage this?

I suppose you meant to say this is Fission-disabled only, from the contexts of previous comments.

Right, I think there's no action for now. We will monitor after Android Fission is released.