1790435 - VoiceOver quick navigation keys stopped working with Firefox 105 Beta under Mac OS Ventura

Status: VERIFIED FIXED

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

Description

[Piotr]

STR:

• With VoiceOver on, visit Mozilla.org and interact with the web content if it doesn't happen automatically
• Press CTRL+option+Command+H to go to the next heading.

Expected: VoiceOver should move to the next heading.

Actual: Even though there are many headings on the page VoiceOver will announce either "Heading not found" if the cursor isn't on a heading or "last heading" if the cursor is on a heading but there are more that should be there.

Additional info:

• This bug can be reproduced with any of the quick navigation shortcuts (VO+Command+Letters, the letters on their own with quicknav turned on or using the rotor gestures on the trackpad)
• The elements list accessed with VO+U is unaffected and can still list all elements of any type
• The issue appears to have started with Firefox 105. I normally use the Nightly and first noticed the problem there 106.0a1 (2022-09-12). I can also reproduce it on Firefox Beta 105.0b9. THe stable version (104.0.2) works correctly. Both the beta and stable tests were done on an empty profile without any extensions or setting changes.
• Toggling the accessibility cache (either with the flag or through Nightly experiments) doesn't have an effect on this - the problem occurs with it either on or off.
• THe problem appears to be contained to Mac OS Ventura. I reproduced it on Developer Beta 7 though the issue was also reproducible with previous builds. I asked someone to test on Mac OS Monterey, and there with the latest nightly the issue doesn't appear (we are both using M1 MacBook Airs)
• Other browsers like Safari and Anything Chromium based also work without problems.

Comment 1

[James Teh [:Jamie]]

Morgan, Eitan, any ideas? I wonder if we regressed something with some of the CTW work? Weird that it can't be reproduced on all versions of MacOS in that case, though.

Comment 2

[Morgan Reschenberg [:morgan]]

how odd... I can't reproduce this, as I don't have a mac running Ventura. Testing with the following example on Nightly seems to behave as expected:

data:text/html,<h1>hello</h1><h2>world</h2><h3>this is a</h3><h4>test</h4>

Eitan, are you running Ventura?

Piotr, if you're able to run mozregression to identify the breaking change that'd be a huge help

Comment 3

[Piotr]

OK, I ran mozregression --good 104 --bad 105 and eventually ended With this result:

33:24.92 INFO: First bad revision: 79cc3e7c7045663d512170b3354f3e29bea95c80
33:24.92 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=97e91d0ee7c673ae2793fce1811318415b0ff8c5&tochange=79cc3e7c7045663d512170b3354f3e29bea95c80

Comment 4

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

Setting Regressed by field after analyzing regression range found by mozregression in comment #3.

Comment 5

[Morgan Reschenberg [:morgan]]

Maybe the change to AccessibleWrap.mm here caused this issue? https://phabricator.services.mozilla.com/D148300#change-I85FknCNfFdO
Eitan, could you look at this and see if that sounds right to you?

Comment 6

[Eitan Isaacson [:eeejay]]

That change would not have any effect on non-aria elements like headings.

This is my unfounded hypothesis:

1. VO on Ventura provides an empty string for AXSearchText in the search predicate when doing quick nav.
2. Since this is a non-null string, MOXSearchInfo::shouldApplyPostFilter evaluates to true and the matched headings are sent to the
   child doc for post-filtering.
3. The change in AccessibleWrap::ApplyPostFilter in the above patch causes a search for an empty string to return false.
4. All headings are eliminated in ApplyPostFilter.

A way to check this hypothesis without installing Ventura is to add AXSearchText : "" to the search predicates in the heading test: https://searchfox.org/mozilla-central/source/accessible/tests/browser/mac/browser_rotor.js#20

Comment 7

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

:nika, since you are the author of the regressor, bug 1772006, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

Comment 8

[Nika Layzell [:nika] (ni? for response)]

I remember we made a change in that bug for a11y in https://searchfox.org/mozilla-central/diff/c15823d07544b1f12af50ba41bea61e97fe32a13/accessible/mac/AccessibleWrap.mm#297, where the string comparison text changed to be unicode-aware. Other than that I think everything should have the same behaviour in that code? Is there some way that could have caused this issue?

Comment 9

[James Teh [:Jamie]]

Triaging as s2 because while Ventura isn't released yet, it will be later this month, at which point we will have major functionality broken for some users.

Comment 10

[Piotr]

Hello again,

I was wondering if there has been any progress on this? Firefox 105 has hit stable, and more importantly Ventura was released to the public yesterday and I heard from at least 2 more people who are also running into this issue so it's probably not something specific just to my system.

Comment 11

[Morgan Reschenberg [:morgan]]

ni'ing me to check this after I upgrade

Comment 12

[Patryk]

I reverted to monterey because of that.

Comment 13

[Morgan Reschenberg [:morgan]]

Attachment: Bug 1790435: Don't apply rotor post-filter if AXSearchText is empty r?eeejay

Comment 14

[Michal Stanke (Mozilla.cz) [:mstanke][:MikkCZ]]

Hi Morgan.

Sorry for bothering you. There are users asking us on the local Twitter account, what is the ETA for this fix to land. Shall we expect a dot release 106, or is it going to make it at least to 107 in two weeks, please?

Thank you in advance.

Comment 15

[Morgan Reschenberg [:morgan]]

No bother at all, thanks for chatting with those users 😁
We'll nominate this for uplift to beta after it's in nightly -- which will hopefully be within the next few days. Just lando'd it :)
If this issue persists after the fix lands, please let us know.

Comment 16

[Morgan Reschenberg [:morgan]]

ni?me to uplift after this is in

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8c57b390bde4
Don't apply rotor post-filter if AXSearchText is empty r=eeejay

Comment 18

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/8c57b390bde4

Comment 19

[Morgan Reschenberg [:morgan]]

Comment on attachment 9301217 [details]
Bug 1790435: Don't apply rotor post-filter if AXSearchText is empty r?eeejay

Beta/Release Uplift Approval Request

• User impact if declined: Users who rely on VoiceOver's quick nav feature will be unable to use that feature in Firefox.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: See C0
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This patch changes a previous null check into a null-or-empty-string check. The surface area is tiny, and it only affects VO users on macOS Ventura.
• String changes made/needed:
• Is Android affected?: No

Comment 20

[Donal Meehan [:dmeehan]]

Comment on attachment 9301217 [details]
Bug 1790435: Don't apply rotor post-filter if AXSearchText is empty r?eeejay

Approved for 107.0b9

Comment 21

[Donal Meehan [:dmeehan]]

https://hg.mozilla.org/releases/mozilla-beta/rev/07f23dd8751a

Comment 22

[Catalin Sasca, Desktop QA [:csasca]]

Reproduced the issue on Firefox 105.0b9 under macOS 13.0 by following the STR provided in Comment 0.

The issue is fixed on Firefox 107.0b9 and Nightly 108.0a1 (2022-11-06).