Closed Bug 1622699 Opened 4 years ago Closed 4 years ago

Remove accessibility.xpcom.traverse_outerdoc pref

Categories

(Core :: Disability Access APIs, task, P2)

task

Tracking

()

RESOLVED FIXED
mozilla76
Tracking Status
firefox76 --- fixed

People

(Reporter: Jamie, Assigned: Jamie)

References

Details

Attachments

(3 files)

The changes in bug 1621517 and bug 1621521 to allow XPCOM child retrieval and hit test methods to traverse into OuterDocAccessibles (XUL browsers) were landed behind a disabled pref. This was done to avoid potentially breaking the Dev Tools A11y Panel given that we're in the middle of re-architecting for Fission. Once the groundwork for this is done, we should evaluate whether these changes cause any problems, address any problems that are encountered and then remove this pref (so this functionality will always be enabled).

See Also: → 1621517, 1621521

In current mozilla-central, I didn't see any problems in the Browser Toolbox either when opening a XUL browser accessible for a content document or when moving the mouse over a content document. However, there may be something I'm missing, and pending Fission patches might change these findings.

Yura, I know you're in the middle of transitioning things here, but is there any chance of you taking a quick look with this pref turned on for both the current a11y panel code and the WIP code for Fission? Linux ATK hit testing now needs to be fixed as well and I'd rather use common code if I can, but because the pref check has to be done in said common code, this is blocked until we can kill this pref. I can't think of a way to apply that pref just for XPCOM without duplicating code or adding an argument to a bunch of functions, which seems extreme given that we're going to remove this pref anyway.

Depends on: 1598299
Blocks: 1598299
No longer depends on: 1598299

Forgot to Ni for comment 2.

Flags: needinfo?(yzenevich)

Yura noted on Matrix:

I looked into this in more details and triaged the error messages I'm seeing in the browser toolbox. The issue I believe is that when fission is enabled, we are now returning a proxy for a "remote" document even though it is still in the same process. This is not going to be an issue for content toolbox but it is problematic for browser toolbox since I would want to limit deepest child at point lookup only to the same process.

The solution we agreed upon was to add a new GetDeepestChildAtPointInProcess method which restricts to Accessibles. That method should fail if run on a ProxyAccessible.

Flags: needinfo?(yzenevich)

(In reply to James Teh [:Jamie] from comment #4)

The solution we agreed upon was to add a new GetDeepestChildAtPointInProcess method which restricts to Accessibles. That method should fail if run on a ProxyAccessible.

Scrap that. We're going to move the pref into xpcAccessible::GetDeepestChildAtPoint.

Spoke to Yura again and we're going back to comment 4: adding GetDeepestChildAtPointInProcess.

Dev Tools A11y Panel interacts with accessibles in the process in which they reside.
It does not (and cannot) deal with ProxyAccessibles.
However, GetDeepestChildAtPoint now walks into the ProxyAccessible tree if appropriate, which is what we want for tests and what normally makes sense.
This patch introduces GetDeepestChildAtPointInProcess, which Dev Tools will use instead.

Assignee: nobody → jteh
Status: NEW → ASSIGNED
Pushed by jteh@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/09d863d39780
part 1: Add nsIAccessible::GetDeepestChildAtPointInProcess. r=yzen
https://hg.mozilla.org/integration/autoland/rev/b6538a37a0cc
part 2: Make the Dev Tools A11y Panel use GetDeepestChildAtPointInProcess. r=yzen
https://hg.mozilla.org/integration/autoland/rev/380eb92fd801
part 3: Remove accessibility.xpcom.traverse_outerdoc pref. r=yzen
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla76
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: