1681909 - VoiceOver text search on web pages does not work.

Status: RESOLVED FIXED

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

Description

[Marco Zehe (:MarcoZ)]

Steps:

1. Go to any web site. I used this code listing. When the page loads, VoiceOver does not focus on the line that is being linked to, so you have to use the Search feature to quickly get to the starting line number.
2. Press VoiceOver+F and enter 136.
3. Press Enter.

Expected: VoiceOver jumps to the table and onto the line number 136.
Actual: VoiceOver lands on the "Go to Homepage" link.

I can reproduce search failures like this on any page, VoiceOver usually just jumps to the next focusable element.

Setting this to a P2 because this is a common usage pattern by VoiceOver usrs on MacOS. They use VoiceOver search rather than Find In Page.

Comment 1

[Marco Zehe (:MarcoZ)]

22:57.34 INFO: Last good revision: efdf6db9196406db53467847018679bd4d9ab956
22:57.34 INFO: First bad revision: 30660f927c456de4a8a68aa69d2d99d951cd9430
22:57.34 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=efdf6db9196406db53467847018679bd4d9ab956&tochange=30660f927c456de4a8a68aa69d2d99d951cd9430

The only accessibility bug in that range is bug 1657418.

Comment 2

[Marco Zehe (:MarcoZ)]

Bumping priority for the 86 work, this should be fixed for the final customer release.

Comment 3

[Dave Hunt [:davehunt] [he/him] ⌚BST]

:MarcoZ can you confirm if this is not needed for 85?

Comment 4

[Marco Zehe (:MarcoZ)]

No, this is not needed for 85.

Comment 5

[Marco Zehe (:MarcoZ)]

Another way to reproduce this:

1. While this bug is displayed, press CTRL+Option+U to open the VoiceOver rotor menu.
2. Press left or right arrow repeatedly until you get to Headings.
3. Focus the first heading, which is labeled "Bugzilla".
4. Start typing s e a r for "Search". This should filter down the list to only those headings that have the word "search" in it.

Result: Instead, the "Bugzilla Home" link is focused, and no matter what you type, it will always be the result displayed/highlighted.

Comment 6

[Eitan Isaacson [:eeejay]]

Attachment: Bug 1681909 - P1: Add IPC stubs for ApplyPostSearchFilter. r?nika!,morgan!

Applying a bulk filter on accessibles in content process allows us to avoid a potentially large (and variable) number of IPC sync calls to retrieve the accessible names. I chose to implement this as a "post filter" and not to actually do the entire search in content because it would cause a lot of duplication of code for non-IPC searching, and we wouldn't have the flexibility to combine a text search with any arbitrary search key as the API requires.

I also generalized the RangeTypes.h header to PlatformExtTypes so it can be used to define filter types as well.

Comment 7

[Eitan Isaacson [:eeejay]]

Attachment: Bug 1681909 - P2: Implement post filter for non-e10s case. r?morgan!

Introducing this as a separate patch to simplify this changeset and first introduce a straightforward-ish implementation.

Depends on D100730

Comment 8

[Eitan Isaacson [:eeejay]]

Attachment: Bug 1681909 - P3: Implement e10s post search filter and test. r?morgan!

The test adds fission testing as well.

Depends on D100731

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c1fed62071ea
P1: Add IPC stubs for ApplyPostSearchFilter. r=morgan,ipc-reviewers,mccr8
https://hg.mozilla.org/integration/autoland/rev/5ff22d8b9cf5
P2: Implement post filter for non-e10s case. r=morgan
https://hg.mozilla.org/integration/autoland/rev/aabdb35d94a1
P3: Implement e10s post search filter and test. r=morgan

Comment 10

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/c1fed62071ea
https://hg.mozilla.org/mozilla-central/rev/5ff22d8b9cf5
https://hg.mozilla.org/mozilla-central/rev/aabdb35d94a1