649720 - Connect toplevel document accessibles with chrome accessible parents

Status: RESOLVED WONTFIX

(Core :: Disability Access APIs, defect)

Description

[Benjamin Smedberg]

For e10s, we're going to be unable to traverse upwards in the accessibility tree from the toplevel document to its chrome parent. We should try to make this return NULL starting today, and see what effects this has on screen readers. I suggest we land this in -central, and maybe back it out in aurora or beta if there's a problem. Or control it with a pref.

Comment 1

[James Teh [:Jamie]]

I understand the issue, but this just isn't workable. NVDA in particular relies on being able to determine correct accessibility hierarchy. If this returns NULL, we won't even be aware that the document is inside the Chrome.

I don't know what the current strategy for implementing e10s a11y is, but if the a11y hierarchy for documents is exposed from the browser process (not the renderer process), why can't you traverse to the chrome, since it will be in the same process? (This would require forwarding the info between the two processes or caching the document a11y tree in the browser process.) Of course, this won't work if the a11y hierarchy is actually being exposed from the renderer process.

Comment 2

[James Teh [:Jamie]]

From email, I gather that there will be a fake HWND in the content process. If this is the case, as long as the content HWND is a child of the chrome HWND, we'll at least revert to returning the client accessible of the parent HWND, which should be the top level frame. (Better still, the document accessible should return the oleacc window (ROLE_SYSTEM_WINDOW) accessible for its HWND, in which case oleacc will handle accParent automatically.)

Even this is still ugly. The hierarchy is still very broken. We only know that the document is a child of the top level frame, not that it is a child of a property page, etc. However, this shouldn't break normal functionality, though it will look bad when using screen reader object navigation.

Comment 3

[James Teh [:Jamie]]

From email concerning retrieving children from the chrome process:
> No. With the "fake widget" we can provide a child using AccessibleObjectFromWindow()... that window will run in the content process. MSAA takes care of the cross-process COM remoting magic.
If the COM marshalling is indeed handled correctly, why not use the same trick with accParent? All you need is the unique ID of the correct parent accessible. Then, just use AccessibleObjectFromEvent(chromeHWND, OBJID_CLIENT, uniqueID).

Slightly off-topic for this bug, but note that if an AT tries to render a document by retrieving it as a child of the chrome, it may end up rendering it out-of-process, which will be incredibly slow. Thankfully, I think most ATs (including NVDA) only render documents in response to events, and if the events come from the fake content HWND, they'll get injected into the correct process.

Comment 4

[Benjamin Smedberg]

What does "rendering it out of process" mean? Since content and chrome are going to be in different processes, something is inherently out-of-process. If you are running code in the Firefox process and making calls to that content IAccessible, you are going to block the chrome process on content, which is very much what we're trying to avoid. I thought that a11y tools always ran in their own process in general.

If .parent is always supposed to have a correct answer, we may need to do that, but given the documentation, it seems that the a11y tool should really be responsible for building the tree from the root and then it just knows the parent. Of course, the MS docs may be worthless in the real world...

Comment 5

[James Teh [:Jamie]]

(In reply to comment #4)
> What does "rendering it out of process" mean? ...
> I thought that a11y tools always ran in
> their own process in general.
Partially. However, when rendering complex documents (including Gecko), most ATs inject in-process because it is much faster. As I noted, I think most only do this in response to an event, in which case they'll be injected into the content process. However, it's just something to check in case we see performance issues with other ATs.

> but given the documentation, it seems that the a11y tool should really be
> responsible for building the tree from the root and then it just knows the
> parent.
Definitely not. Building the entire hierarchy would be unacceptably inefficient in terms of both speed and memory, particularly out-of-process.

Comment 6

[alexander :surkov (:asurkov)]

Jamie, if we create fake HWNDs for content processes, so separate accessible tree per each window, i.e. no unified tree then is it possible/how hard to make NVDA working? Can you foresee any unsolvable problems?

Comment 7

[James Teh [:Jamie]]

(In reply to comment #6)
> Jamie, if we create fake HWNDs for content processes, so separate accessible
> tree per each window, i.e. no unified tree then is it possible/how hard to
> make NVDA working? Can you foresee any unsolvable problems?
Document rendering should still work; see comment #2. However, breaking the hierarchy like this is bad because it makes it impossible for the user to see the relationship between the document and the chrome; e.g. that the document is beneath the tab. Personally, I think this would be a *huge* regression. I still think the approach suggested in comment #3 is worth trying.

Comment 8

[alexander :surkov (:asurkov)]

How do you use or expose to use that this particular document is beneath some tab? Can you give an example?

> I still think the approach suggested in comment #3 is worth trying.
Do we have any performance issues here?

On the another hand if you get an accessible belonging to content process (for example, by AccessibleObjectFromEvent) and then start crawling up the hierarchy (accessibles resides in chrome process). It appears you should block two processes since all calls are sync?

Comment 9

[James Teh [:Jamie]]

(In reply to comment #8)
> How do you use or expose to use that this particular document is beneath
> some tab? Can you give an example?
Actually, I'm not strictly correct because Firefox document property pages (tabs) have no name, so we don't bother to report them to the user. However, it will still break object navigation for the user. In NVDA, you can move around the object hierarchy (though we simplify it somewhat by removing layout objects). So, for example, the user might want to move out of the document to find the tab bar or status bar or some other part of the chrome. They should be able to see where the document is in relation to the rest of the hierarchy.

> > I still think the approach suggested in comment #3 is worth trying.
> Do we have any performance issues here?
I'm not certain. It really depends how the marshaller handles it. Even so, you need to do this to expose documents as children of the chrome, so you're going to have the same problem there.

> On the another hand if you get an accessible belonging to content process
> (for example, by AccessibleObjectFromEvent) and then start crawling up the
> hierarchy (accessibles resides in chrome process). It appears you should
> block two processes since all calls are sync?
First, in-process, we never go *above* the document when rendering a buffer, so we wouldn't be blocking for an entire render. Second, out-of-process, we're hoping that the marshaller is smart enough to short circuit when talking to a remote process and asked to marshal an object from yet another remote process. We can't be sure of this without testing it, unfortunately. As I said above, you're going to have this same problem when exposing documents as children of the chrome.

Comment 10

[Chris Peterson [:cpeterson]]

Mass tracking-e10s flag change. Filter bugmail on "2be0fcce-e36a-4e2c-aa80-0e3d33eb5406".