Closed Bug 419770 Opened 13 years ago Closed 13 years ago
can't get to the frame/iframe of a document with IAccessible::acc
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).
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?
This might be the same has bug 397800.
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?
This will appear in try server builds in about 30 minutes: https://build.mozilla.org/tryserver-builds/2008-02-27_14:email@example.com-NodeChildOfToSkipDisruptiveRoleWindowObjects/
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".
Just the right changes, remove the superfluous stuff :)
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 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
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Try server builds with the newer fix are here: https://build.mozilla.org/tryserver-builds/2008-02-27_15:firstname.lastname@example.org-NodeChildOfToSkipDisruptiveRoleWindowObjects/
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
Attachment #306145 - Flags: approval1.9? → approval1.9+
checked in by aaronlev
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.