1325244 - Crash in mozilla::a11y::DocAccessibleChild::ConstructChildDocInParentProcess

Status: RESOLVED DUPLICATE of bug 1325258

(Core :: Disability Access APIs, defect)

Description

[Ting-Yu Chou [:ting] (away)]

This bug was filed from the Socorro interface and is 
report bp-aeca4bc7-bdcd-4328-ac79-7099c2161219.
=============================================================
Top #24 of Nightly 20161218030213 on Windows, 8 crashes from 3 installations. The first appearance was 20161217030205.

Comment 1

[Ting-Yu Chou [:ting] (away)]

It seems the |parentIPCDoc| at https://dxr.mozilla.org/mozilla-central/rev/c36fbe84042debef0a5d58b7fc88185b401762ce/accessible/base/NotificationController.cpp#864 is null.

Comment 3

[Nicholas Nethercote [inactive]]

davidb: another one for your radar.

Comment 4

[(No longer employed by Mozilla) Aaron Klotz]

My best guess atm is this sequence of events:

1) e10s is running but a11y is not;
2) Some event triggers a11y startup. Note that due to bug 1269369, we haven't actually created top-level DocAccessibles yet;
3) Some stuff happens in the page that triggers an attempt to bind child docs to the non-existent top-level doc.

That's the only case that makes sense in my mind where the parent IPC doc could possibly be nullptr when we try to bind children. I think this would just go away with the landing of bug 1269369.

Comment 5

[(No longer employed by Mozilla) Aaron Klotz]

Hmm... On second thought, I don't think that makes any sense either.

Since we are executing inside NotificationController, it follows that its owner is the DocAccessible for the parent doc...

Comment 6

[(No longer employed by Mozilla) Aaron Klotz]

The only other way that I hypothesize that this can happen is if the docshell doesn't have a TabChild. Is that even possible?