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

RESOLVED FIXED in Firefox 51

Status

()

defect
--
major
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: jackarmley, Assigned: eeejay)

Tracking

unspecified
mozilla51
Unspecified
Android
Points:
---

Firefox Tracking Flags

(firefox51 fixed)

Details

Attachments

(1 attachment)

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
Severity: normal → major
Component: Untriaged → Disability Access
OS: Unspecified → Android
Eitan, can you take a look please?
Component: Disability Access → Disability Access APIs
Flags: needinfo?(eitan)
Product: Firefox → Core
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.
Flags: needinfo?(eitan)
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.
Flags: needinfo?(eitan)
(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.
Flags: needinfo?(eitan)
Fair enough, thanks!
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
Attachment #8767019 - Flags: review?(surkov.alexander) → review+
Assignee: nobody → eitan
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Pushed by cbook@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/44bd5c188aa6
Use DOM instead of layout in HTMLComboboxAccessible::SelectedOption. r=surkov
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/44bd5c188aa6
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
You need to log in before you can comment on or make changes to this bug.