1685106 - Crash in [@ mozilla::dom::WindowContext::HasValidTransientUserGestureActivation]

Status: RESOLVED FIXED

(Core :: DOM: Content Processes, defect, P2)

Description

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Regressed by bug 1684490, we will back out the switch to the diagnostic assert.

Maybe Fission related. (DOMFissionEnabled=1)

Crash report: https://crash-stats.mozilla.org/report/index/643c57fd-31f1-44be-85ce-cd19b0210105

MOZ_CRASH Reason: MOZ_DIAGNOSTIC_ASSERT(mInProcess)

Top 10 frames of crashing thread:

0 xul.dll mozilla::dom::WindowContext::HasValidTransientUserGestureActivation docshell/base/WindowContext.cpp:397
1 xul.dll nsDocShell::InternalLoad docshell/base/nsDocShell.cpp:9382
2 xul.dll nsDocShell::LoadHistoryEntry docshell/base/nsDocShell.cpp:11742
3 xul.dll nsDocShell::LoadHistoryEntry docshell/base/nsDocShell.cpp:11672
4 xul.dll nsDocShell::LoadURI docshell/base/nsDocShell.cpp:837
5 xul.dll mozilla::dom::ContentChild::RecvLoadURI dom/ipc/ContentChild.cpp:4136
6 xul.dll mozilla::dom::PContentChild::OnMessageReceived ipc/ipdl/PContentChild.cpp:13120
7 xul.dll mozilla::ipc::MessageChannel::DispatchMessage ipc/glue/MessageChannel.cpp:2077
8 xul.dll mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal xpcom/threads/TaskController.cpp:739
9 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1200

Comment 1

[Emilio Cobos Álvarez (:emilio)]

So the only way we can hit this that I can see is the ConsumeUserActivation call touched in bug 1684490, and this other HasValidTransientUserGestureActivation call. From the stack I guess it's the second, since I don't think we store a lot of unknown protocol URIs in history.

In both cases, we should either be hitting a definitely-in-process context, or mBrowsingContext->GetCurrentWindowContext(). Nika, is there any case where mBrowsingContext->GetCurrentWindowContext() isn't supposed to be in process?

Comment 2

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

(In reply to Emilio Cobos Álvarez (:emilio) from comment #1)

In both cases, we should either be hitting a definitely-in-process context, or mBrowsingContext->GetCurrentWindowContext(). Nika, is there any case where mBrowsingContext->GetCurrentWindowContext() isn't supposed to be in process?

BrowsingContext::GetCurrentWindowContext() is never guaranteed to be in-process, as it can easily be called on a cross-process BrowsingContext. During the edge cases around process switching it wouldn't surprise me too much if code could run in an old DocShell which doesn't own the current WindowContext, which could trigger an assertion there. The check should probably be extended to check context && context->IsInProcess() or similar.

I haven't looked too deeply, but it might be possible for this to happen when switching an out-of-process iframe back to being in-process, as the first load in that nsDocShell may happen before the nsDocShell has lazily created its initial about:blank document, meaning that the current WindowContext may still be in the previous remote process.

Comment 3

[Chris Peterson [:cpeterson]]

assign to kmag

M7 Beta

Comment 4

[Kris Maglione [:kmag]]

Attachment: Bug 1685106: Add some missing IsInProcess() checks to nsDocShell. r=nika

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/73f2c610465e
Add some missing IsInProcess() checks to nsDocShell. r=nika

Comment 6

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/73f2c610465e

Comment 7

[Daniel Bodea [:danibodea]]

This is a one occurrence potential startup crash that appears to have been fixed.
Does it require verification? If it does, please NI me and provide the necessary info to do so.
Thank you.

Comment 8

[Kris Maglione [:kmag]]

No verification necessary.