616452 - Dynamically inserted select options aren't reflected in accessible tree

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Marco Zehe (:MarcoZ)]

STR:
1. With a current nightly build, including the try-server build for bug 498015, file a bug in Core/Disability Access APIs or anywhere you like.
2. Try to request blocking 2.0 on the bug you are filing.

Expected: When focusing the combobox and pressing DownArrow, the ? would be selected.
Actual: The combobox appears empty.

3. Another instance: Go to http://twitter.com/#inbox and log in with your Twitter account.
4. Try to select an item from the combobox you want to send a direct message to.

Expected: An alphabetical list of names should appear.
actual: Nothing is selectable.

I cannot verify whether this is really empty visually, or if it is just us reporting no entries and no focus change.

With FX 3.6, this works fine.

Other, more static comboboxes, work fine.

Comment 1

[Fernando Herrera]

I can confirm this. Visually it is not empty, but this is the sequence of events we get with ff4:

object:state-changed:invalid-entry(1, 0, None)
        source: [combo box | Send a direct message.]
object:state-changed:invalid-entry
object:state-changed:focused(1, 0, None)
        source: [combo box | Send a direct message.]
object:state-changed:focused

and with ff3 it is:

focus:(0, 0, None)
        source: [menu item | acruiz]
focus:
object:state-changed:focused(1, 0, None)
        source: [menu item | acruiz]
object:state-changed:focused

Comment 2

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

Fernando, what does "(1, 0, None)" mean?

Comment 3

[Fernando Herrera]

(In reply to comment #2)
> Fernando, what does "(1, 0, None)" mean?

That comes from spying at-api events, that is really easy.

Here "1" is the detail of the event, that means the focused is true, "0" and "None" are detail2 extra details, that for this kind of event they are going to be always 0 and None

Comment 4

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

OK. So in the FF4 case the invalid-entry state is becoming true?

Comment 5

[Fernando Herrera]

The problem here is that dynamically added options are not added to the a11y tree. I'm attaching a mochitest for this.

Comment 6

[Fernando Herrera]

Attachment: mochitest case

Comment 7

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

Comment on attachment 495029 [details]
mochitest case

>    //gA11yEventDumpID = "debug";

What does uncommenting this give you?

Comment 8

[alexander :surkov (:asurkov)]

Attachment: patch

hacky (didn't think hard), thanks for mochitest

Comment 9

[alexander :surkov (:asurkov)]

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


>+    function addOptions(aID, aCount)

I've hardcoded "aCount = 2" into invoker locally

Comment 10

[alexander :surkov (:asurkov)]

Attachment: patch2

that's better

Comment 11

[Marco Zehe (:MarcoZ)]

Comment on attachment 495247 [details] [diff] [review]
patch2

>+  <title>bug 616452 tests</title>

Capital "Bug", please. ;)

Comment 12

[alexander :surkov (:asurkov)]

(In reply to comment #11)

> >+  <title>bug 616452 tests</title>
> 
> Capital "Bug", please. ;)

changed on"Add select options test"

Comment 13

[Fernando Herrera]

Comment on attachment 495247 [details] [diff] [review]
patch2

Great, good catch!
r=me

Comment 14

[alexander :surkov (:asurkov)]

landed on 2.0 - http://hg.mozilla.org/mozilla-central/rev/ed4d22fad16a