560239 - no children of application accessible for open windows before accessibility was started

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[alexander :surkov (:asurkov)]

If there are open windows and then you start accessibility service and get children of application accessible then application accessible doesn't contain accessible for open windows in children. This happens because root accessible adds itself to application accessible children, so there is no root accessibles created if their windows were open before accessibility was started and therefore they are missed from the tree. We should be more smart when we return application accessible children, i.e. we should create root accessibles when children were requested.

Comment 1

[alexander :surkov (:asurkov)]

Attachment: patch

1) make sure accessibles for all window documents are created before the work with children of application accessible
2) the mochitest doesn't test the bug until it runs in standalone mode, any way it's good to have it
3) the mochitest is disabled since events/test_scroll.xul results in appending the the unexpected root accessible into application accessible children and that breaks the mochitest. I'll investigate the issue and file another bug. I inspected application accessible children by DOMi (bug 551404) and can confirm this bug is fixed.

Comment 2

[Marco Zehe (:MarcoZ)]

Comment on attachment 440150 [details] [diff] [review]
patch

>+  // Basicly children are kept updated by Add/RemoveRootAccessible method

Nit: "basically".

>+  // that all root accessible are stored in application accessible children

Nit: "all root accessibles".

>+    // Note: but 560239 can be tested if this test runs in standalone mode only.

Nit: "bug 560239..."

>+    var gWnd = window.openDialog(gURL, "wnd", "chrome,width=600,height=600");

Question: Do we know that 600 by 600 is available on every Tinderbox?

With the nits fixed and the question answered, r=me.

Comment 3

[[e-mail]]

Comment on attachment 440150 [details] [diff] [review]
patch

>+  // Basicly children are kept updated by Add/RemoveRootAccessible method
Basically

(git-apply found two lines with trailing spaces)

I was slightly disappointed that the "Inspect Application Accessible" patch that I used for testing caused the accessibility service to always register DOM Inspector first, while the other windows appeared in creation order. (I'm assuming that this is partly due to the application accessible cache only getting fully populated when you specifically enumerate its children.)

Comment 4

[alexander :surkov (:asurkov)]

(In reply to comment #3)

> I was slightly disappointed that the "Inspect Application Accessible" patch
> that I used for testing caused the accessibility service to always register DOM
> Inspector first, while the other windows appeared in creation order. 

Yes, this is because they are registered in the order of root document accessible creation, since DOMi starts accessibility service then root document accessible is created for it first of all.

Comment 5

[David Bolter [:davidb] (NeedInfo me for attention)]

Comment on attachment 440150 [details] [diff] [review]
patch

r=me - sorry for delay.

(In reply to comment #1)
> 3) the mochitest is disabled since events/test_scroll.xul results in appending
> the the unexpected root accessible into application accessible children and
> that breaks the mochitest. I'll investigate the issue and file another bug.

Yes please. If you could file and reference the bug # in a test comment in this patch it would be great.

Comment 6

[alexander :surkov (:asurkov)]

(In reply to comment #2)

> Question: Do we know that 600 by 600 is available on every Tinderbox?

I think yes because we used this in other tests

Comment 7

[alexander :surkov (:asurkov)]

landed on 1.9.3 

http://hg.mozilla.org/mozilla-central/rev/a0167136f56b
http://hg.mozilla.org/mozilla-central/rev/524d7a18043a (reviewer comments)