1786240 - [CTW] Live regions are broken with JAWS

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect)

Description

[James Teh [:Jamie]]

STR:

1. Start JAWS.
2. Start Firefox with CTW enabled.
3. Open this test case:
   data:text/html,<div aria-live="polite" id="live"></div><script>let number = 1; function update() { live.textContent = number++; setTimeout(update, 1000); } update();</script>
   • Expected: JAWS should read an incrementing number every second; 1, 2, 3, ...
   • Actual: JAWS says nothing.
4. Press alt+d to focus the address bar.
   • Observation: JAWS now reads an incrementing number every second; 1, 2, 3, ...

Step 4 shows that we're exposing the live region correctly, but I don't understand why it only works when focus is outside of the document.

Comment 1

[James Teh [:Jamie]]

I've sent an email to Vispero asking for help figuring this out, as I have no clue.

Comment 2

[Marco Zehe (:MarcoZ)]

I can reproduce. On the Braille display, I see the number go up every second when in the virtual buffer. Outside the virtual buffer, the numbers get pushed as a "help balloon" text, and also sent to the Braille display as flash messages.

Comment 3

[Marco Zehe (:MarcoZ)]

Another piece of info I just discovered: I pressed "Follow" on a different bug here in Bugzilla. JAWS switched to forms mode, and the live region that says "You are now following this bug" was immediately announced. So it seems to be enough to be in forms mode, but focus can still be in the document, for JAWS to announce the live regions. Only if virtual cursor is on, announcements don't work.

Comment 4

[James Teh [:Jamie]]

Yeah, I got similar results when I forced the virtual cursor off. Just to make things more fun, I have seen this work a few times even with the virtual cursor on, but refreshing the document breaks it. I still can't fathom what's different between the two situations.

Comment 5

[James Teh [:Jamie]]

Deferring to m3. I would have liked to get this fixed before we launched the preview, but I'm blocked waiting on info from Vispero.

Comment 6

[James Teh [:Jamie]]

For the record, this is not fixed by bug 1789378 or bug 1793710.

Comment 7

[James Teh [:Jamie]]

Attachment: Bug 1786240: Clear a cached BUSY state before firing doc load complete.

Comment 8

[James Teh [:Jamie]]

Some additional info for the record:
JAWS ignores live regions if it thinks the document is busy. All of my debugging suggests we are correctly firing a state change event when the document finishes loading and loses its busy state, and accState is correctly returning a value without the busy state as soon as that event fires (even for callers within NotifyWinEvent). JAWS does not seem to agree. Delaying the state change event by 500 ms also seems to fix this, so I suspect there is some race condition going on here within JAWS.
The other thing worth noting is that currently, the tracking of busy state within JAWS is a single global state for all documents. If one document goes busy, all documents will be treated as busy. If one document stops being busy, all documents will now be treated as not busy. You can reproduce this by doing various things with busy and non-busy documents in two different tabs.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9f2676f2b893
Clear a cached BUSY state before firing doc load complete. r=morgan

Comment 10

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/9f2676f2b893

Comment 11

[Ardelean Oana, Desktop QA [:oardelean]]

I managed to reproduce this issue on a 2022-08-21 Nightly build on Windows 10 using the STR from the Description. Verified as fixed on Firefox 107.0b4(build ID: 20221023190001), Nightly 108.0a1(build ID: 20221023100414) on Windows 10.