Closed Bug 1691345 Opened 4 years ago Closed 4 years ago

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

Categories

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

Unspecified
macOS
defect

Tracking

()

RESOLVED FIXED
87 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox85 --- unaffected
firefox86 --- unaffected
firefox87 --- fixed

People

(Reporter: aryx, Assigned: eeejay)

References

(Regression)

Details

(Keywords: crash, regression, Whiteboard: [Mac2020_2])

Crash Data

Attachments

(1 file)

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
Flags: needinfo?(eitan)

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

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.
Severity: -- → S2
Priority: -- → P2
Assignee: nobody → eitan
Status: NEW → ASSIGNED
Pushed by eisaacson@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/d94de995a62b
Check that focused child doc is a descendant of caller's doc. r=Jamie
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 87 Branch
Priority: P2 → P1
Whiteboard: [Mac2020_2]
Flags: needinfo?(eitan)
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: