Closed Bug 1325244 Opened 6 years ago Closed 6 years ago

Crash in mozilla::a11y::DocAccessibleChild::ConstructChildDocInParentProcess

Categories

(Core :: Disability Access APIs, defect)

Unspecified
Windows 10
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 1325258
Tracking Status
firefox50 --- unaffected
firefox51 --- unaffected
firefox52 --- affected
firefox53 --- affected

People

(Reporter: ting, Assigned: tbsaunde)

References

Details

(Keywords: crash, Whiteboard: aes+)

Crash Data

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.
Duplicate of this bug: 1325248
Flags: needinfo?(aklotz)
Whiteboard: aes+
davidb: another one for your radar.
Flags: needinfo?(dbolter)
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.
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...
The only other way that I hypothesize that this can happen is if the docshell doesn't have a TabChild. Is that even possible?
Assignee: nobody → tbsaunde+mozbugs
Flags: needinfo?(dbolter)
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1325258
You need to log in before you can comment on or make changes to this bug.