1875629 - VoiceOver loses cache contents in background tabs if no element on the page is focused when switching away

Status: VERIFIED FIXED

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

Description

[Marco Zehe (:MarcoZ)]

Pages in the background lose their accessibility cache if no item was focused when the user switched to a different tab or opened a new one. The STR are, roughly, as follows:

1. With VoiceOver on, open a page in a tab.
2. Without reading through any page elements, open a new tab and open a pdifferent page. On this page, make sure to navigate to an element that can take focus such as a link or a form field, before switching away from the tab.
3. For good measure, repeat step 1 with a third tab, but again make sure to not focus any element.
4. Press CTRL+Tab to switch back to the first tab.
   • Expected: VoiceOver should have access to all elements on the page.
   • Actual: VoiceOver only sees the document, or the first element on the page, but nothing else.
5. Press CMD+F5 to turn VoiceOver off, then once more to turn it back on again.
6. Issue a reading command such as trying to interact with the HTML content.
   • Result: VoiceOver will once again read the contents. On very complex pages, even a very tiny delay might be noticeable as Firefox rebuilds its accessibility cache.
7. Now, press CTRL+Tab to switch to the page opened in step 2. This is the page where we explicitly focused an element. Try to read more elements on the page.
   • Result: Everything works as expected.
8. Press CTRL+Tab once more. This will switch to the tab opened in step 3, where we once again didn't focus an element. Try to read elements with VoiceOver.
   • Result: Same as step 4, elements won't be available.
9. Repeat steps 5 and 6.
   • Result: Results wwill be the same, restarting VoiceOver and having it read the page content elements will force Firefox to rebuild its cache.

This does not happen in Safari.

I don't know when this was introduced. I only know that when I started using Firefox on the Mac full-time again in October of 2023, the problem was present in the then current release version. Note that due to stress reducage, I refrain from using Nightly builds nowadays. I have never seen this behavior on Windows.

Comment 1

[Morgan Reschenberg [:morgan]]

:MarcoZ how are you getting VO to avoid focusing anything on a page you open?
Did you disable "Automatically read web page" in the VoiceOver Utility?

I'm having trouble reproducing this, VO loads and reads content from backgrounded tabs without delay for me

:eeejay were you able to repro ?

Comment 2

[Marco Zehe (:MarcoZ)]

No, I did not disable automatic reading of web pages. If I load a page, and VoiceOver starts reading it, I press ctrl to stop speech immediately. I then do something like Cmd+T for new tab etc., work in there for a bit, and when I return to the page I loaded previously in the other tab, where I stopped speech, the content is no longer accessible, until I either trigger a new page load by tabbing to a link or pressing enter, pressing Cmd+R to refresh, or turning VoiceOver off and on again.

Comment 3

[Morgan Reschenberg [:morgan]]

:ayeddi, can you give this a test?

Comment 4

[Anna Yeddi [:ayeddi]]

(In reply to Morgan Reschenberg [:morgan] from comment #3)

:ayeddi, can you give this a test?

:morgan, I was not able to reproduce it too on my M1 with macOS 14.3.1 running today's Nightly and the local build of current central: after ctrl+Tab not the entire page is being announced, but the area with first focusable element on it (i.e. a cookie banner on Pocket or the empty main on Bugzilla)

Comment 5

[Marco Zehe (:MarcoZ)]

If you hit a situation where you can only read the currently focused item instead of being able to navigate around all elements on the page with VO+Left and VO+Right, you are hitting the bug.

Comment 6

[Eitan Isaacson [:eeejay]]

Took me a few tries, but I managed to reproduce. I'll look into this further.

Comment 7

[Eitan Isaacson [:eeejay]]

Seems to be a bit site specific. I turned of VO auto-read. What works for me:

1. In new window do cmd+l, type in mozilla.org
2. page loads and cursor lands on "mozilla image link"
3. Do cmd+t to open new tab.
4. Type facebook.com, enter.
5. After load navigate a bit.
6. Do ctrl+tab to mozilla.org tab
7. Press VO+left

Result: cursor refuses to leave "mozilla image link".

Comment 8

[Eitan Isaacson [:eeejay]]

We aren't losing cache contents. Using rotor on the "dead" page works as expected.

When changing tab, VoiceOver's cursor gets set to the keyboard input focus in that tab. Some VoiceOver quirk is trapping the cursor in that item.

Comment 9

[Eitan Isaacson [:eeejay]]

I think this has to do with how we reset focus and on what when we switch tabs...

Comment 10

[James Teh [:Jamie]]

Eitan, any progress on this? This one is an s2, so we need to figure out a path forward.

Comment 11

[James Teh [:Jamie]]

(In reply to Eitan Isaacson [:eeejay] from comment #7)

1. In new window do cmd+l, type in mozilla.org
2. page loads and cursor lands on "mozilla image link"

...

7. Press VO+left

Result: cursor refuses to leave "mozilla image link".

Isn't that expected because the Mozilla image link is the first thing on the page? If you wanted to move outside of the web content, you'd need to stop interacting with it (VO+shift+up). VO+right does seem to work to move to the next element though.

Comment 12

[James Teh [:Jamie]]

This is easiest to reproduce if you have a page which has nothing focusable on it. When I do this, even restarting VoiceOver doesn't "fix" this sometimes.

STR:

1. Open this URL:
   data:text/html,<h1>foo</h1>bar
2. Explore using VO+right and VO+left. Observe that you can reach both "foo" and "bar".
3. Open another tab with any page.
4. Press control+tab to return to the tab you opened in step 1.
5. Press VO+right.
   • Expected: VoiceOver should say: "bar"
   • Actual: VoiceOver bonks and stays on "foo"

Comment 13

[James Teh [:Jamie]]

You don't even need to switch tabs:

1. Open this URL:
   data:text/html,<h1>foo</h1>bar
2. Explore using VO+right and VO+left. Observe that you can reach both "foo" and "bar".
3. Shift+tab to move focus into the navigation toolbar.
4. Tab to move focus back to the document.
5. VO+right.
   • Expected: bar
   • Actual: bonk, foo

And this isn't just about focus:

1. Open this URL:
   data:text/html,<h1>foo</h1>bar
2. Explore using VO+right and VO+left. Observe that you can reach both "foo" and "bar".
3. Shift+tab to move focus into the navigation toolbar.
4. VO+shift+up to stop interacting with the toolbar.
5. VO+right to move to the web content.
6. VO+shift+down to interact with it.
7. VO+right.
   • Expected: bar
   • Actual: bonk, foo

Comment 14

[James Teh [:Jamie]]

More findings:

1. VoiceOver isn't able to set focus to the document when you navigate with the VO cursor. I've filed bug 1898198 for that. I doubt that's the problem here, since this also happens when you control+tab (where Firefox itself sets the focus), but it's inconsistent with Safari and it's annoying anyway, so it's probably worth fixing.
2. I tried fudge redirecting web area focus onto the root group. We don't really want that because it causes weird focus reporting, but interestingly, it does fix the bug when you tab out of and back into the web area.
3. When this failure occurs, VO seems to completely forget about the web area as a container you have to interact with. That is, VO+left from the first element inside the web area takes you to the navigation toolbar and VO+right from there takes you to the first element inside the web area. It's very odd because one minute, the web area is something you have to interact with, and the next, it isn't.
4. When this failure occurs, VO doesn't seem to call AXChildren on the root group, which seems really strange. I guess it caches them somewhere, but why does its cache get messed up? It certainly calls AXParent a lot though.

Comment 15

[Eitan Isaacson [:eeejay]]

Attachment: Bug 1875629 - Add AXContents to outer docs (scroll areas). r?morgan

Without this attribute VoiceOver gets into an unstable state when the cursor or focus
leaves the document.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3349c81bf456
Add AXContents to outer docs (scroll areas). r=morgan

Comment 17

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/3349c81bf456

Comment 18

[Ina Popescu, Desktop QA]

Despite multiple attempts to reproduce this issue, I was unable to do so, even after following the STR mentioned in all the previous comments. @eeejay, could you please provide a simplified test case, or any other suggestions that might help in reproducing this issue? Thanks.

Comment 19

[Marco Zehe (:MarcoZ)]

My system just upgraded to Firefox 128 release, and I can confirm that this bug is fixed on the sites I previously encountered it on.

Comment 20

[Eitan Isaacson [:eeejay]]

Thanks Marco. I'm going to mark this as verified.

Comment 21

[Ina Popescu, Desktop QA]

Updating the remaining flag based on Comment 19.