1374979 - [e10s a11y] In Gmail, the Inbox label disappears from NVDA's virtual buffer when focused

Status: RESOLVED WORKSFORME

(Core :: Disability Access APIs, defect)

Description

[Marco Zehe (:MarcoZ)]

STR:
1. Run NVDA and Firefox in E10S mode.
2. Log into Gmail.
3. Focus will most likely land on the Inbox table.
4. Press LeftArrow to move focus to the list of labels. NVDA will speak the Inbox label as a link, but not switch to browse mode, as it usually does.
5. Press DownArrow. Focus will move to the Starred label, and now browse mode is invoked, and the virtual buffer becomes active.
6. Press UpArrow.

Expected: NVDA should again read the Inbox link, and focus should move there visually, too.

Actual: NVDA will read the Labels heading 2 instead, skipping over the Inbox label.

I have also tried to refresh the virtual buffer, but for me, the label does not get reinserted. But from object navigator (a slightly advanced way of traversing the actual accessibility tree in NVDA itself), I can find the Inbox label to be present.

My suspicion is that either, we're missing to fire an event when the Inbox label gains or loses focus. I notice in non-E10S mode that there's a graphic that appears and disappears depending on whether Inbox has focus or not. Perhaps the event sequence gets somehow messed up in E10S mode.

Or, we're firing the events, but NVDA is not consuming them properly any more, for whatever reason. I have filed a related NVDA ticket, too, and Jamie said there that there were no recent changes in the Gecko support code that could account for this. The issue is https://github.com/nvaccess/nvda/issues/7310.

Comment 1

[James Teh [:Jamie]]

While it's possible that there is some event breakage here, it's not events alone. If it were just events, refreshing the buffer would fix the issue, since that crawls the tree completely without any state from events. There are a few possibilities:

1. IAccessibleText doesn't contain an embedded object character corresponding to the link.
2. There's an embedded object character, but IAccessibleHypertext::hyperlinkIndex fails.
3. hyperlinkIndex succeeds, but IAccessibleHypertext::hyperlink fails.
4. hyperlink succeeds, but QueryInterface to IAccessible2 fails.
5. QI to IA2 succeeds, but the accessible is broken in some way; e.g. IAccessibleText doesn't return text, IAccessibleHypertext is broken or the accessible returns a width/height of 0.

I can't reproduce this, which is going to make this difficult to debug. I think possibilities 1 to 4 are more likely, so let's ignore 5 for now.

Here's how you can test this. When this occurs, use NVDA object navigation to get to the inbox link. Then, open the NVDA Python console. Set up by entering the following:

from IAccessibleHandler import IAccessibleHyperlink

Now, we're going to have to walk up the parents, checking that IAccessibleHypertext and IAccessibleHyperlink are behaving as expected. Following is an example session. The >>> bits are the commands I'm typing. The bits without >>> are example output from the console. I've also put some comments in prefixed by #.

# Start with the navigator object (the Inbox link).
>>> o = nav
>>> hl = o.IAccessibleObject.QueryInterface(IAccessibleHyperlink)
>>> s = hl.startIndex; s
1
>>> ht = nav.parent.iaHypertext
>>> hi = ht.hyperlinkIndex(s); hi
1
>>> ht.hyperlink(hi)
<POINTER(IAccessibleHyperlink) ptr=0xb09fd7c at 7bd8440>
# At this point, we know that hyperlinkIndex and hyperlink work.
# Let's move on to the next parent.
>>> o = o.parent
>>> hl = o.IAccessibleObject.QueryInterface(IAccessibleHyperlink)
>>> s = hl.startIndex; s
0
>>> ht = nav.parent.iaHypertext
>>> hi = ht.hyperlinkIndex(s); hi
0
>>> ht.hyperlink(hi)
<POINTER(IAccessibleHyperlink) ptr=0xb0c6c1c at 7bd8030>
# Now we know they work for this parent. Up we go.
>>> o = nav.parent

... and so on. You can use the up arrow key to move through history to make this easier. You may have to go up a few parents before you hit a problem.

Comment 2

[James Teh [:Jamie]]

Arrg. I wrote:
o = nav.parent
at the end. I meant:
o = o.parent

I also wrote:

> 1. IAccessibleText doesn't contain an embedded object character corresponding to the link.

This is possible, but it's also possible this is actually related to an ancestor of the link, since each label has several levels of descendants. That's why we crawl up the ancestry with the hypertext/hyperlink stuff.

Comment 3

[Marco Zehe (:MarcoZ)]

Can no longer reproduce. Closing as WFM.