Closed Bug 1332731 Opened 3 years ago Closed 3 years ago

TalkBack stopped working in web content

Categories

(Firefox for Android :: General, defect)

50 Branch
defect
Not set

Tracking

()

RESOLVED FIXED
Firefox 54
Tracking Status
fennec + ---
firefox-esr52 --- unaffected
firefox53 + verified
firefox54 --- verified

People

(Reporter: roy.nickelson, Assigned: jchen)

References

(Blocks 1 open bug)

Details

(Keywords: access, regression)

Attachments

(1 file, 1 obsolete file)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161208153507

Steps to reproduce:

start TalkBack
Navigate to 
https://labs.ssbbartgroup.com/index.php/ARIA_Checkbox_role
Navigate to one of the check boxes



Actual results:

Talkback announces Button


Expected results:

TalkBack should announce check box
tracking-fennec: --- → ?
Hi Sorina,
If this bug can be reproduced, could you provide a regression window?
Flags: needinfo?(sorina.florean)
Regression window:
Last known good build: 2016-12-10
First known bad build: 2016-12-11

Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8404d26166a35406f46ff237ed132735c98882b2&tochange=c51e7406d7b2e2246a1ece0d8989282ca752039f

Device: Huawei MediaPad M2 (Android 5.1.1).
Flags: needinfo?(sorina.florean)
Changes from Jim & Eugen during that day.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(nchen)
Flags: needinfo?(esawin)
Assignee: nobody → nchen
Blocks: 1321418
Status: NEW → ASSIGNED
Flags: needinfo?(nchen)
Flags: needinfo?(esawin)
Follow-up to fix breakage in accessibility caused by the bundle
conversion. In particular, optString(foo) should have been converted to
getString(foo, "") because optString returns "" by default.

Also fix a small bug in Presentation.jsm where an array or null should
be used instead of a string.
Attachment #8833593 - Flags: review?(s.kaspari)
Updated patch
Attachment #8834066 - Flags: review?(s.kaspari)
Attachment #8833593 - Attachment is obsolete: true
Attachment #8833593 - Flags: review?(s.kaspari)
Attachment #8834066 - Flags: review?(s.kaspari) → review+
Duplicate of this bug: 1331946
tracking-fennec: ? → +
Pushed by nchen@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/ffddbc50a846
Follow-up to fix accessibility breakage; r=sebastian
https://hg.mozilla.org/mozilla-central/rev/ffddbc50a846
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 54
Verified as fixed in build 54.0a1 (2017-02-16);
Device: Asus ZenPad 8 (Android 6.0.1).
Comment on attachment 8834066 [details] [diff] [review]
Follow-up to fix accessibility breakage (v2)

Approval Request Comment
[Feature/Bug causing the regression]: Bug 1321418
[User impact if declined]: TalkBack accessibility feature does not work on web content
[Is this code covered by automated tests?]: No
[Has the fix been verified in Nightly?]: Yes, and Aurora/Beta.
[Needs manual test from QE? If yes, steps to reproduce]: No
[List of other uplifts needed for the feature/fix]: None
[Is the change risky?]: No
[Why is the change risky/not risky?]: Patch has been on 54+ for a while, but was never uplifted to 53.
[String changes made/needed]: None
Attachment #8834066 - Flags: approval-mozilla-release?
Hi Liz, we should consider including this fix in 53.0.1. This fix has been on 54 for almost 2 months and verified by SoftVision.
Flags: needinfo?(lhenry)
Keywords: regression
I've seen several recent examples of a regression marked only as tracking-fennec:+ but not marked as affected for a particular version. I think we have a good chance here to improve how our triage systems work together. 

I'd like to suggest: when you see new issues, please add the "regression" keyword and possibly "regressionwindow-wanted".  We should be all be proactive about it. When did the issue start? How bad is this regression for users? What versions does it affect? Should we uplift the fix?   

We need to ask those questions so that we can avoid shipping regressions, or fix those regressions as soon as possible. So, we have to just go a little bit beyond landing the patch and verifying the bug was fixed in Nightly. 

This will really help, because then you will get all the "machinery" of QE, release management, and platform triage (engineering managers) noticing fennec issues, and getting the fixes where they should be.  

n-i to some folks in this bug, to make sure you see my comment, not because this needs any reply. 
I will also send my suggestion to the release-drivers mailing list.
Flags: needinfo?(whuang)
Flags: needinfo?(sorina.florean)
Flags: needinfo?(s.kaspari)
Flags: needinfo?(nchen)
Flags: needinfo?(lhenry)
Flags: needinfo?(kbrosnan)
Flags: needinfo?(kbrosnan)
Comment on attachment 8834066 [details] [diff] [review]
Follow-up to fix accessibility breakage (v2)

Broke accessibility on release, let's uplift this and test.
Attachment #8834066 - Flags: approval-mozilla-release? → approval-mozilla-release+
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #12)
> I'd like to suggest: when you see new issues, please add the "regression"
> keyword and possibly "regressionwindow-wanted".  We should be all be
> proactive about it. When did the issue start? How bad is this regression for
> users? What versions does it affect? Should we uplift the fix?

Got it and I agree. I should have done better here, and I will remember these points in the future. Thanks!
Flags: needinfo?(nchen)
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #12)
> I've seen several recent examples of a regression marked only as
> tracking-fennec:+ but not marked as affected for a particular version. I
> think we have a good chance here to improve how our triage systems work
> together. 
> 
> I'd like to suggest: when you see new issues, please add the "regression"
> keyword and possibly "regressionwindow-wanted".  We should be all be
> proactive about it. When did the issue start? How bad is this regression for
> users? What versions does it affect? Should we uplift the fix?   
> 
> We need to ask those questions so that we can avoid shipping regressions, or
> fix those regressions as soon as possible. So, we have to just go a little
> bit beyond landing the patch and verifying the bug was fixed in Nightly. 
> 
> This will really help, because then you will get all the "machinery" of QE,
> release management, and platform triage (engineering managers) noticing
> fennec issues, and getting the fixes where they should be.  
> 
> n-i to some folks in this bug, to make sure you see my comment, not because
> this needs any reply. 
> I will also send my suggestion to the release-drivers mailing list.

Will do that in the feature. Thanks!
Flags: needinfo?(sorina.florean)
Flags: needinfo?(s.kaspari) → needinfo?(max)
Agree. We will also do that in future Fennec triage meeting. Thanks, Sebastian. :)
Flags: needinfo?(max)
Flags: needinfo?(whuang)
Hello, 

I've verified this issue in 54.0b2 Beta build and the latest Nightly, the issue seems to be reproducible, as described in Comment 0. Could this be a new regression maybe or was the fix never applied to these builds?
Flags: needinfo?(lhenry)
Hi Bogdan, It looks like the fix hasn't landed on release yet, but I'm a bit worried that it also may not be on 54.  Wes can you take a look and make sure this has really landed on 54?
Flags: needinfo?(lhenry) → needinfo?(wkocher)
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #18)
> Hi Bogdan, It looks like the fix hasn't landed on release yet, but I'm a bit
> worried that it also may not be on 54.  Wes can you take a look and make
> sure this has really landed on 54?

Patch landed on m-c when m-c was 54. I'd assume a new regression. Can qa track down a new regression range to see when it popped back up on 54? Perhaps :bogdan can run a Nightly build from right after this originally landed to see if the fix could be verified?
Flags: needinfo?(wkocher)
Bogdan, can you follow up?  
Jim, can your team in Taipei help? 
This is our main blocker right now for the fennec 53 dot release.  
The patch here hasn't landed on mozilla-release yet. But, we think it may not have worked in 54. 
It sounds like there is potentially an issue on 53, 54, and 55. Maybe a different cause than the original issue?
Flags: needinfo?(nchen)
Flags: needinfo?(bogdan.surd)
The STR in comment 0 works for me. The checkboxes are announced as "check button", which is the expected behavior AFAICT.
Flags: needinfo?(nchen)
(In reply to Roy Nickelson from comment #0)
> User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:50.0) Gecko/20100101
>
> Expected results:
> 
> TalkBack should announce check box

 The expected result is that they should be announced as check boxes, not buttons. If it's ok that they are announced as buttons, the issue can be considered as fixed and verified.
Flags: needinfo?(nchen)
If an element has a Roll of Checkbox then it should be announced as a checkbox. A checkbox is not the same as a button. The roll indicates to the user how to interact with the control.  
The expected behavior is Talkback will announce something like option 1 check box not checked when activating the check box by Double tapping on it Talkback should announce checked.
I still can't tell, on which branches does this now work, and on which is it still broken? 
Does TalkBack work in general for content now? And on which branches? 

I would think that check boxes are different than buttons, since they have different behavior for users. 

David, I wonder if you can help here since this is a pretty big accessibility issue affecting our release population.
Flags: needinfo?(dbolter)
Keywords: access
It looks like this is fixed everywhere except 53, but it looks like it will be in 53.0.1.
Wes could you land this on m-r? Thanks!
Flags: needinfo?(wkocher)
(In reply to Roy Nickelson from comment #23)
> If an element has a Roll of Checkbox then it should be announced as a
> checkbox. A checkbox is not the same as a button. The roll indicates to the
> user how to interact with the control.  
> The expected behavior is Talkback will announce something like option 1
> check box not checked when activating the check box by Double tapping on it
> Talkback should announce checked.

We should probably open another bug about changing "check button" to "check box". Unfortunately there was a different bug that broken TalkBack completely, and that issue ended up being worked on in this bug.
Flags: needinfo?(nchen)
Summary: TalkBack announces Check Boxes as buttons → TalkBack stopped working in web content
See Also: → 1360113
Duplicate of this bug: 1358131
Device: Honor 8 (Android 6.0)
Builds:
 - 53.0.1 (Build 2)
 - 54.0b2
You need to log in before you can comment on or make changes to this bug.