Closed Bug 1681909 Opened 1 year ago Closed 1 year ago

VoiceOver text search on web pages does not work.


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

Firefox 85



86 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox84 --- wontfix
firefox85 --- wontfix
firefox86 --- fixed


(Reporter: MarcoZ, Assigned: eeejay)




(Keywords: regression, Whiteboard: [Mac2020_2])


(3 files)


  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.

22:57.34 INFO: Last good revision: efdf6db9196406db53467847018679bd4d9ab956
22:57.34 INFO: First bad revision: 30660f927c456de4a8a68aa69d2d99d951cd9430
22:57.34 INFO: Pushlog:

The only accessibility bug in that range is bug 1657418.

Has Regression Range: --- → yes
Keywords: regression
Regressed by: 1657418

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

Priority: P2 → P1

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

Flags: needinfo?(mzehe)

No, this is not needed for 85.

Flags: needinfo?(mzehe)
Assignee: nobody → mreschenberg

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.

Assignee: mreschenberg → nobody
Assignee: nobody → eitan

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.

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

Depends on D100730

The test adds fission testing as well.

Depends on D100731

Pushed by
P1: Add IPC stubs for ApplyPostSearchFilter. r=morgan,ipc-reviewers,mccr8
P2: Implement post filter for non-e10s case. r=morgan
P3: Implement e10s post search filter and test. r=morgan
You need to log in before you can comment on or make changes to this bug.