Updates incorrectly reported for lie regions in background tabs in Firefox

[nvaccessAuto]

Updated description for clarity:

Currently, NVDA reports off-screen live regions. This is because we want to report regions which have been placed off-screen so they are only read by screen readers. Unfortunately, content in background tabs is also marked off-screen. And in Firefox, all tabs share the same HWND, so we can't use the HWND to determine whether a tab is in the background. This means we can't tell the difference between author off-screen live regions and live regions in background tabs in an efficient, standard way. However, we definitely shouldn't be reading live regions in the background.

STR:

1. Open this test case in Firefox:
   data:text/html,<div id="live" aria-live="polite">Initial content</div><script>setTimeout(() => live.textContent = "Updated live content", 2000);</script>
2. Quickly (within 2 seconds), press control+t to open a new tab.
3. Wait 2 seconds.
   • Expected: NVDA should not say "Updated live content"
   • Actual: Within 2 seconds, NVDA says "Updated live content"

Original description (for historical purposes):

Reported by modulus on 2011-01-11 19:54
When reading changes taking place on the Chatzilla window (and presumably on Firefox in general) the tab where those changes take place (which in Chatzilla's case represents the channel) is not announced. This makes it difficult to join several channels.

[nvaccessAuto]

Comment 1 by jteh on 2011-01-12 00:21
Tabs other than the currently active tab are not supposed to be read at all. Are you seeing cases where this happens? If so, this would seem to be a reappearance of #138.
Changes:
Milestone changed from None to None

[nvaccessAuto]

Comment 2 by pvagner on 2011-01-12 12:41
Hello,
I have just tested and it really looks as if that issue is back again.
I've just tried to use ChatZilla 0.9.86 in Firefox/3.6.13. Except of the default chatzilla window, I've connected to the irc.mozilla.org server, joined several channels one after the other and while idling having the focus inside the tab for the second channel, events from the first channel were spoken.
I need to take a look on that issue and try if I can do something.

[nvaccessAuto]

Comment 3 by jteh on 2011-01-12 15:36
Is this with Gecko 2/Firefox 4? If so, the problem is that all tabs are in the same window in Gecko 2, so the window states can't be used anymore. This means that it is really important that Mozilla fix the bug with states on their side.

[dkager]

Maybe worth re-testing, unless Gecko experts can confirm that this is fixed in later versions than FF 3.

[jcsteh]

As far as I know, this bug still exists.

[Adriani90]

@Modulus, @pvagner are you still seeing this issue in NVDA 2019.1.1 and Firefox 67?

[pvagner]

Hello,

On my end This can still be reproduced with NVDA 2019.1 and Firefox 67 on Windows and Firefox 69 and Orca master on linux.

Easier steps to reproduce than chatzilla:

• Open the page at https://terrillthompson.com/tests/aria/live-scores.html
• 2 Hit Start game 2 button and notice how your screen reader of choice announces the region changes.
• Press ctrl+t to open a new tab.
• 4 navigate a bit on the new tab to make sure the focus is in the document content.

Results:
Aria-live region announcements continue even when the tab where they are originated from is no longer in focus.

It would be interesting to find out a corresponding Mozilla bug for this one.

To me it looks platform neutral or at least it may affect even more users than we have expected.

[jcsteh]

There isn't a Mozilla bug at this stage. The problem is that there's no clear way to map this in current accessibility APIs.

objects in background tabs do get the offscreen state. Unfortunately, web authors use off-screen live regions to make screen readers speak information which isn't visible, so screen readers can't ignore off-screen live regions. We still need to fire the events because otherwise, screen reader virtual buffers wouldn't be updated. (Granted, this last point isn't an issue on Linux.)

To solve this, we need some other way to generically communicate that an accessible is in the background. This needs to be something standard; there are hacks NVDA could use to detect this in Firefox specifically, but that wouldn't work for other IA2 implementations.

[Adriani90]

It seems @derekriemer is also looking into this. See #9079.

[jcsteh]

I updated the issue description for clarity.

It seems @derekriemer is also looking into this. See #9079.

That PR is indeed about live regions, but this problem is out of scope there.

I just realised this isn't an issue for Chrome, since Chrome uses different HWNDs for different tabs. That makes it less important to try to standardise a new solution. Also, Firefox already provides a relation to get the tab document for a given accessible, as well as a relation to get the currently active document from the root. We could use those to fix this. I'll try to find time to submit a PR.

[lukaszgo1]

I'm afraid it is not fixed for me in some cases, the main one being new messages on messenger.com.
To reproduce:
1 Login to messenger in the one tab and open conversation on which you expect a new message.
2. Switch to the another tab.
3. Wait for the new message.

The message is being read even though the messenger tab is opened in the background.
cc @jcsteh

[jcsteh]

Can you reproduce the problem with this URL? data:text/html,<div aria-live="polite" id="live"></div><script>let i = 1; function tick() { live.textContent = i++; setTimeout(tick, 1000); } tick();</script> If not, please file a separate issue for the Messenger problem. Thanks.

[Adriani90]

is the message exposed via live region? I know that some messengers expose the new message via notification, i.e. toast notifications. But you are on Win7. Right? Von meinem iPhone gesendet

…

Am 22.04.2020 um 13:38 schrieb Łukasz Golonka ***@***.***>:  I'm afraid it is not fixed for me in some cases, the main one being new messages on messenger.com. To reproduce: 1 Login to messenger in the one tab and open conversation on which you expect a new message. 2. Switch to the another tab. 3. Wait for the new message. The message is being read even though the messenger tab is opened in the background. cc @jcsteh — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.