1721666 - Fission crash in [@ mozilla::a11y::DocAccessibleParent::AddChildDoc]

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[u608768]

Maybe Fission related. (DOMFissionEnabled=1)

Crash report: https://crash-stats.mozilla.org/report/index/4a9c814f-559d-42d4-834a-5a6570210719

MOZ_CRASH Reason: MOZ_DIAGNOSTIC_ASSERT(false) (Binding to parent that isn't a valid OuterDoc!)

Top 10 frames of crashing thread:

0 xul.dll mozilla::a11y::DocAccessibleParent::AddChildDoc accessible/ipc/DocAccessibleParent.cpp:593
1 xul.dll mozilla::a11y::DocAccessibleParent::AddChildDoc accessible/ipc/DocAccessibleParent.cpp:706
2 xul.dll mozilla::dom::BrowserParent::RecvPDocAccessibleConstructor dom/ipc/BrowserParent.cpp:1257
3 xul.dll mozilla::dom::PBrowserParent::OnMessageReceived ipc/ipdl/PBrowserParent.cpp:2824
4 xul.dll mozilla::dom::PContentParent::OnMessageReceived ipc/ipdl/PContentParent.cpp:6587
5 xul.dll mozilla::ipc::MessageChannel::DispatchMessage ipc/glue/MessageChannel.cpp:2011
6 xul.dll mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal xpcom/threads/TaskController.cpp:805
7 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1148
8 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:107
9 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:324

Bug 1713680 dealt with a similar crash. All crashes have Fission enabled.

Comment 1

[James Teh [:Jamie] (away returning 12 Jan)]

Ug. This bug is still showing up, despite my multiple attempts to fix it. I still can't reproduce it locally, which makes things very difficult.

Comment 2

[James Teh [:Jamie] (away returning 12 Jan)]

Hypothesis:

1. An OuterDocAccessible gets created for a visible iframe. Its id is sent as the embedder accessible on the PBrowserBridge.
2. The iframe is hidden. The OuterDocAccessible gets destroyed.
3. A new Accessible is created with the same id as sent in 1). It is sent to the parent process.
4. While the iframe is still hidden, the embedded document is created. (This could either be the original load or a reload.)
5. The parent process will try to add the document as a child of the accessible with the id from 1), since that id is still set on the BrowserBridgeParent.
6. Pain and suffering ensues.

If I'm right (and given how many times I've tried to fix this bug, there's no guarantee of that 🙁), the solution is probably to clear the embedder accessible on the PBrowserBridge when the OuterDocAccessible is destroyed. I'm not sure whether a new OuterDocAccessible can be created before the old one is shut down. If it can, we'll need to make sure a new embedder accessible hasn't already been sent to parent.

Comment 3

[Chris Peterson [:cpeterson]]

Tracking for Fission M8. This is a medium-volume a11y crash affecting Beta users in our Fission experiment. e10s users are not affected.

Jamie, I'm tentatively assigning this bug to you. If you don't think this bug needs to block shipping Fission, just let me know.

Comment 4

[James Teh [:Jamie] (away returning 12 Jan)]

Attachment: Bug 1721666: Clear the embedder accessible on PBrowserBridge if that accessible is destroyed.

If an iframe is hidden, its OuterDocAccessible will be destroyed, but the PBrowserBridge still exists.
Since the OuterDocAccessible was destroyed, its id can be reused.
Therefore, if a new embedder accessible hasn't already been set, clear the embedder accessible on PBrowserBridge.
This ensures that the wrong accessible can't accidentally be used when an OOP iframe document is added while the iframe is hidden.

Comment 5

[Chris Peterson [:cpeterson]]

This bug is a hard blocker for Fission M8.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/921fdd1dd807
Clear the embedder accessible on PBrowserBridge if that accessible is destroyed. r=eeejay

Comment 7

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/921fdd1dd807