419770 - can't get to the frame/iframe of a document with IAccessible::accParent

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Michael Curran]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b4pre) Gecko/2008022604 Minefield/3.0b4pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b4pre) Gecko/2008022604 Minefield/3.0b4pre

the parent property of an IAccessible/IAccessible2 document object is an IAccessible window object. The parent of the IAccessible window object is the client object of the parent window.
For example:
Going up by parent from the main document of firefox:
document < window < Minefield frame (the root client object for the Firefox app).
Same as with a subDocument with in another document (via an iframe):
document < window < top document

However, using accessibleChildren, or IEnumVariant or firstChild etc, going down from an IFrame, you can get to the document.

I can understand why the parent of the window is the client of the parent window, as the window object is something provided completely by MSAA, and not Gecko. However, I would suggest that Gecko should override the parent property on any root object (such as a document), and make sure it points to the true parent in the parent window, rather than just pointing to the generic MSAA window object for that window.
 So for example:
The parent of a subdocument should be its iframe
This will not only make it much more efficient for ATs to support the dynamic loading of an iframe (after the main page has loaded) but it will also fix some inconsistancies, where going up by parent from the main document, does not give access to the propertypage and grouping object etc (like going down does).
This change is also very important as ATs usually cache focus ancestors (retreaved by going parent all the way to the top of the hyerarchy) but in these cases, its actually quite incorrect.

Reproducible: Always

Steps to Reproduce:
1. Open firefox and load any document
2. With Accessibility probe, locate the document that was loaded. (note the order of ancestors you needed go go in to to get there)
3. In the properties for this document object, keep expanding accessible parent (note that you do not pass through all the ancestors you did in the explorer view, but only window and then the root frame for the app).

Comment 1

[Michael Curran]

Although my sollution (in the bug description) will solve the problem. It should be noted that this will greatly break the WindowFromAccessibleObject oleacc.dll function. As WindowFromAccessibleObject simply goes up the ancestor chain looking for a window object. So what will happen is it will always return the  top-level window of the app.
IAccessible2::get_windowHandle probably should be used in most cases, however I have seen it return windows that are a bit strange... though this should be submitted as another bug. 
Perhaps another fix could be to provide an Accessiblerelation on the document, pointing to the iframe?

Comment 2

[Aaron Leventhal]

This might be the same has bug 397800.

Comment 3

[Aaron Leventhal]

Looking at this now I see this is not the same as bug 397800.

Mick, you're right that your proposed solution would break WindowFromAccessibleObject(). We can't break that, because some current generation screen readers rely on that.

We could consider using the NODE_CHILD_OF relation on the document to point to the parent. How about that?

Comment 4

[Aaron Leventhal]

Attachment: Provide NODE_CHILD_OF relation to point to parent of a doc, to skip over MSAA's disruptive ROLE_WINDOW objects

Comment 5

[Aaron Leventhal]

This will appear in try server builds in about 30 minutes:
https://build.mozilla.org/tryserver-builds/2008-02-27_14:[e-mail]-NodeChildOfToSkipDisruptiveRoleWindowObjects/

Comment 6

[Aaron Leventhal]

Attachment: Provide NODE_CHILD_OF relation to point to parent of anything in a new window, to skip over MSAA's disruptive ROLE_WINDOW objects which block further parent traversal

In this patch we essentially borrow the logic to see if we're in a window from nsAccessibleWrap::get_accParent. If we are in such a window then get_accParent will provide the ROLE_WINDOW object, so NODE_CHILD_OF can provide the alternate "real parent".

Comment 7

[Aaron Leventhal]

Attachment: Provide NODE_CHILD_OF relation to point to parent of anything in a new window, to skip over MSAA's disruptive ROLE_WINDOW objects which block further parent traversal

Just the right changes, remove the superfluous stuff :)

Comment 8

[Aaron Leventhal]

Try server builds are being created for the new builds.  They will be in the newer of the two directories with "NodeChildOfToSkipDisruptiveRoleWindowObjects" in the title.

The difference in this fix from the previous one is that it provides the same workaround for accessibles with css overflow, that have their own window. Thus it helps with bug 397800, as long as clients are willing to try NODE_CHILD_OF before accParent.

Comment 9

[alexander :surkov (:asurkov)]

Comment on attachment 306145 [details] [diff] [review]
Provide NODE_CHILD_OF relation to point to parent of anything in a new window, to skip over MSAA's disruptive ROLE_WINDOW objects which block further parent traversal


>+      // If accessible is in its own Window then we should provide NODE_CHILD_OF relation
>+      // so that MSAA clients can easily get to true parent instead of getting to oleacc's
>+      // ROLE_WINDOW accessible which will prevent us from going up further

would be nice to mention nsAccessibleWrap::acc_getParent where the logic comes from.

and it would be nice to mention this relation in nsAccessibleWrap::get_accParent

and if you would write more details about problem then it's nice too (please expand "which will prevent us from going up further")

with this r=me

Comment 10

[Aaron Leventhal]

Try server builds with the newer fix are here:
https://build.mozilla.org/tryserver-builds/2008-02-27_15:[e-mail]-NodeChildOfToSkipDisruptiveRoleWindowObjects/

Comment 11

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 306145 [details] [diff] [review]
Provide NODE_CHILD_OF relation to point to parent of anything in a new window, to skip over MSAA's disruptive ROLE_WINDOW objects which block further parent traversal

a1.9=beltzner

Comment 12

[alexander :surkov (:asurkov)]

checked in by aaronlev