1691345 - Crash in [@ mozilla::ipc::FatalError | mozilla::ipc::IProtocol::HandleFatalError | mozilla::a11y::PDocAccessibleParent::SendFocusedChild]

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect, P1)

Description

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

So far only 1+ user sending crash reports but they encountered 11 crashes with 6 installations.

Crash report: https://crash-stats.mozilla.org/report/index/5ad8630a-ea02-4977-9713-8c9f40210203

MOZ_CRASH Reason: MOZ_CRASH(IPC FatalError in the parent process!)

Top 10 frames of crashing thread:

0 XUL mozilla::ipc::FatalError ipc/glue/ProtocolUtils.cpp:189
1 XUL mozilla::ipc::IProtocol::HandleFatalError const ipc/glue/ProtocolUtils.cpp:423
2 XUL mozilla::a11y::PDocAccessibleParent::SendFocusedChild ipc/ipdl/PDocAccessibleParent.cpp:7465
3 XUL mozilla::a11y::ProxyAccessible::FocusedChild accessible/ipc/other/ProxyAccessible.cpp:794
4 XUL -[mozAccessible moxFocusedUIElement] accessible/mac/mozAccessible.mm:245
5 XUL -[MOXAccessibleBase accessibilityFocusedUIElement] accessible/mac/MOXAccessibleBase.mm:383
6 XUL -[MOXAccessibleBase accessibilityFocusedUIElement] accessible/mac/MOXAccessibleBase.mm:383
7 AppKit -[NSWindow accessibilityFocusedUIElement] 
8 AppKit _NSAccessibilityFocusedAttributeValue 
9 XUL -[BaseWindow accessibilityAttributeValue:] widget/cocoa/nsCocoaWindow.mm:3456

Comment 1

[James Teh [:Jamie]]

The IPC error is "Error deserializing 'PDocAccessible'". This looks awfully like bug 1631276 comment 5, except your code should already handle this case. Strange.

Comment 2

[James Teh [:Jamie]]

Oh. I see the problem.

My code to support DocAccessibleChild::IsConstructedInParentProcess on non-Windows assumes that a top level doc can never have queries made against it unless it has been constructed in the parent process. Before your FocusedChild patch, this was true: if the top level doc isn't constructed in the parent process yet, it's impossible to query that doc from the parent at all. The problem is that DocAccessible::FocusedChild can return a document from a completely different ancestry, even a different top level doc. That's where things get potentially nasty: that other top level doc might not be constructed in the parent yet.

In order for this to happen, dom::BrowserParent::GetFocused must be out of sync with that content process's idea of a11y focus. I guess there are race conditions where that's possible; i.e. where parent hasn't caught up with content or vice versa.

I see three possible fixes here:

1. Get rid of the assumption about top level doc construction in the parent and have top level docs send an explicit message just like child docs do. That does mean more (mostly pointless) IPC trafic, though.
2. Fix DocAccessible::FocusedChild so it can only return a descendant. That might break assumptions elsewhere, though. I don't think any Windows clients depend on this assumption, but they might.
3. Tweak DocAccessibleChild::RecvFocusedChild to ensure the doc is a descendant before returning it.

Comment 3

[Eitan Isaacson [:eeejay]]

Attachment: Bug 1691345 - Check that focused child doc is a descendant of caller's doc. r?Jamie!

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d94de995a62b
Check that focused child doc is a descendant of caller's doc. r=Jamie

Comment 5

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/d94de995a62b