Windows content processes require fully-fledged application accessibles

RESOLVED FIXED in Firefox 57

Status

()

enhancement
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: aklotz, Assigned: aklotz)

Tracking

(Blocks 2 bugs)

Trunk
mozilla57
Unspecified
Windows
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox57 fixed)

Details

(Whiteboard: aes+)

Attachments

(1 attachment)

In bug 1023509 this was changed so that a content application accessible is just an ApplicationAccessible. On Windows we actually need this to be an ApplicationAccessibleWrap since ATs can directly interact with it.

Reported by Brett while working on JAWS stuff.
Attachment #8910028 - Flags: review?(dbolter)
Whiteboard: aes+
Comment on attachment 8910028 [details] [diff] [review]
Use ApplicationAccessibleWrap in content

Review of attachment 8910028 [details] [diff] [review]:
-----------------------------------------------------------------

Oh. Yeah I guess we need this so we can give them a IID_IAccessibleApplication interface?
Attachment #8910028 - Flags: review?(dbolter) → review+
(In reply to David Bolter [:davidb] (NeedInfo me for attention) from comment #2)
> Oh. Yeah I guess we need this so we can give them a
> IID_IAccessibleApplication interface?

When trying to resolve it from a content accessible, yes. Brett tells me that JAWS resolves application accessibles off of the accessible provided with events.

I suppose that we could modify this in the future so that content always returns the browser's application accessible but this is the best short-term fix.
https://hg.mozilla.org/integration/mozilla-inbound/rev/a86e0e1c7c6318e9664af75c05bcb3ea79687cf4
Bug 1401392: Use ApplicationAccessibleWrap for content application accessible on Windows; r=davidb
https://hg.mozilla.org/mozilla-central/rev/a86e0e1c7c63
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
Blocks: 1401755
You need to log in before you can comment on or make changes to this bug.