1380027 - OSX VoiceOver cursor does not respond to tab key press with e10s

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect, P3)

Description

[umer.farooq]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170628075643

Steps to reproduce:

Start Firefox it will ask you to enable accessibility. 
Click on "Enable (restart required)".

After restart it will ask again to enable accessibility with same popover and this behavior is continuous. 


Actual results:

VoiceOver unable to recognize its TAB key movement. Suppose I'm using TAB key to navigation between links, VO will not announce any of link.


Expected results:

TAB key should be recognized on site and every focus able element should be announced.

Comment 1

[sadikshahidain]

I ran into this today too trying to run my standard accessibility test cases today for Firefox on OSX. Ashamedly I haven't done that in a while though so I'm not sure when this surfaced...

Comment 3

[Marius Coman [:mcoman], Ecosystem QA]

User Agent  Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:57.0) Gecko/20100101 Firefox/57.0 
Firefox: 57.0a1, Build ID 20170822142709

I have tested this issue on latest Firefox release (55.0.2), on latest Beta (56.0b5) and latest Nightly (57.0a1) build. I have managed to reproduce it using the steps provided in the description. 
However is seems that this issue is related to e10s. If e10s is deactivated (about:config > browser.tabs.remote.autostart > false) this issue is no longer reproducible. VoiceOver works like expected.

Comment 4

[Jim Mathies [:jimm]]

We should investigate this and prioritize. Support here has been spotty since e10s rolled out. We don't officially support this but it'd be great if we could.

Comment 5

[Stephen A Pohl [:spohl]]

Marking this to be prioritized.

Comment 7

[Marco Zehe (:MarcoZ)]

Morgan, is this actually still valid? I just tabbed through a few pages with VoiceOver on, and VoiceOver cursor was always where the focused item was, e. g. I could press tab a few times in Bugzilla or on mozilla.org, and when I then navigated with CTRL+Option+RightArrow, I continued from where focus was, so VoiceOver cursor was following. This may have been fixed by one of the other bugs. Can you confirm? Also NI'ing Marius to see if he can still reproduce with a current Nightly build on Catalina or Mojave.

Comment 8

[Morgan Reschenberg [:morgan]]

WFM, but I think Eitan mentioned to me moderately recently that he was having issues with this behaviour being consistent (or maybe the issue was VO wouldn't focus the web area consistently, like safari? I'm not sure... ni?'ing him here).

Comment 9

[Marius Coman [:mcoman], Ecosystem QA]

Hi Marco, I have tested this issue and it seems that it is no longer reproducible on the latest Firefox Nightly (76.0a1 Build ID - 20200317214918) and latest Firefox Beta (75.0b4 Build ID - 20200317211402). Now, the VoiceOver follows the focus and recognize the links.
However, I have managed to reproduce the issue on the latest Firefox Release (74.0 Build ID - 20200309095159) using the steps from the description.

Considering the above, using the mozregression tool I have managed to find the fix. Here is the pushlog:

First good revision: 14a1863166fca4a218a687cf04a750577b1c567a
Last bad revision: 96695fc2f0f257540907d87ec2d0479bc422fd76
Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=96695fc2f0f257540907d87ec2d0479bc422fd76&tochange=14a1863166fca4a218a687cf04a750577b1c567a

From the pushlog, it seems that Bug 1617301 has fixed this issue.

I hope it helps :).

Comment 10

[Marco Zehe (:MarcoZ)]

Thank you for the investigation and verification, Marius! Closing as FIXED and linking to the actual fixing bug.

Comment 11

[Marco Zehe (:MarcoZ)]

Verified as per comment #9.

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Comment 13

[Eitan Isaacson [:eeejay]]

Thanks for verifying!