1279214 - when a select option is chosen Talkback does not announce the new state of the select

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[jackarmley]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36
Firefox for Android

Steps to reproduce:

On: Nexus 9/Android M/Talkback.

Using this test page: http://s.codepen.io/jackarmley/debug/NNEEjM

1. Load the page
2. Turn on Talkback
3. Swipe to the select dropdown. It will read "Item 1 collapsed has popup combo box"
4. Double tap the dropdown to bring up
5. Select the second option


Actual results:

Option selector closes, and Talkback says "Firefox".
If you swipe away and back it will read "Item 1 collapsed has popup combo box"

This shows it will read the original state on swipe back, and no state at all when an option is initially selected.


Expected results:

Upon close and swipe away and back selected option should be read out

Seems related to https://bugzilla.mozilla.org/show_bug.cgi?id=1165997

Comment 1

[Marco Zehe (:MarcoZ)]

Eitan, can you take a look please?

Comment 2

[Eitan Isaacson [:eeejay]]

Attachment: Bug 1279214 - Use DOM instead of layout in HTMLComboboxAccessible::SelectedOption.

Review commit: https://reviewboard.mozilla.org/r/61732/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/61732/

Comment 3

[Eitan Isaacson [:eeejay]]

The nsIAccessble.value does not get updated when the selection is changed in Android.

From what I understand, we currently query the collapsed popup list in the frame tree for the selected item.
This doesn't work on Android because the layout list is not used. Instead there is a native dialog popup, and that in turn changes the selection in DOM programmatically.

So the most reliable source for knowing the selected option is DOM, not layout.

Comment 4

[Marco Zehe (:MarcoZ)]

Eitan, is there a way to test for this? If possible, we should make sure areas like these don't regress again in the future by any changes we make.

Comment 5

[Eitan Isaacson [:eeejay]]

(In reply to Marco Zehe (:MarcoZ) from comment #4)
> Eitan, is there a way to test for this? If possible, we should make sure
> areas like these don't regress again in the future by any changes we make.

I can't put this in a mochitest, unfortunately. I can only reproduce this issue in Android. I suspect that the frame tree for the options list is simply not added in Android.

Comment 6

[Marco Zehe (:MarcoZ)]

Fair enough, thanks!

Comment 7

[alexander :surkov (:asurkov)]

Comment on attachment 8767019 [details]
Bug 1279214 - Use DOM instead of layout in HTMLComboboxAccessible::SelectedOption.

https://reviewboard.mozilla.org/r/61732/#review60340

r=me, sorry it took that long to finish it

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/44bd5c188aa6
Use DOM instead of layout in HTMLComboboxAccessible::SelectedOption. r=surkov

Comment 9

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/44bd5c188aa6