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

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.

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.

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

As far as I know, this bug still exists.

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

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.

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.

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

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.

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