Broken accessibility tree when expanding a Gmail conversation
Categories
(Core :: Disability Access APIs, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr60 | --- | unaffected |
firefox-esr68 | --- | unaffected |
firefox68 | --- | unaffected |
firefox69 | --- | unaffected |
firefox70 | --- | fixed |
People
(Reporter: Jamie, Assigned: eeejay)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file)
STR:
- Open a Gmail conversation containing more than one message.
- Press ; (semi-colon) to expand the conversation.
- Press p to focus the first message.
- Press shift+f10 to open the context menu, then choose Inspect Accessibility Properties.
- Expand the listitem, then the section.
- Count the children of the section.
- Expected: 4.
- Actual: 5.
- Look at the first child of the section.
- Expected: It's a grouping.
- Actual: It should be a table.
- Note that the following steps are irrelevant once this is fixed.
- Select the first grouping child of the section.
- Examine the states.
- Observe: The invisible state is present.
This is a regression introduced by bug 686400. When you expand the conversation, the message snippets are hidden with display: none and the full messages are added. For some reason, the message snippets aren't being pruned from the tree. Worse, because they have no frame (hence the invisible state), Accessible::AppendTextTo doesn't produce an embedded object character for them. That results in the text of the parent returning one less embedded object character than it should, which means that the last child (the container for the full message) isn't traversed by clients. The practical impact is that NVDA's virtual buffer doesn't render the full message at all, even if you force refresh.
Note that the message snippet grouping is actually a tbody. There's no table parent because it has role="presentation". However, even removing role="presentation" from the table before expanding doesn't fix this, so I don't think role="presentation" is the issue here.
I really don't follow what's going on here. I would think display: none on the ancestor div should cause layout to notify us about an insertion, and at that point, we should run DocAccessible::PruneOrInsertSubtree, which should recurse and remove the tbody with no frame.
I've tried test cases like this:
data:text/html,<style>table, tbody, tr, td { display: block; }</style><div id="container"><table role="presentation"><tbody><tr><td>Table</td></tr></tbody></table></div><button onClick="container.style.display = 'none';">Hide</button>
Clicking the Hide button works as expected; the tbody gets pruned from the tree.
I do see that there's display: flex somewhere in the Gmail tree, which might cause layout to behave differently somehow?
Comment 1•5 years ago
|
||
I can confirm that there is some issue with hiding certain things. I am seeing this on a banking site as well where, when expanding a sub section, the snippet bits are hidden as well, and are still visible in the tree, causing similar inconsistent issues with NVDA's buffer. I found it this morning and just hadn't got around to filing it yet. Glad Jamie found this in Gmail, which is something we all can easily reproduce.
Assignee | ||
Comment 2•5 years ago
|
||
This is happening because the fix in bug 686400 didn't account for container elements that have no accessibles. In the gmail case, a container with an accessible gets reframed (in my case div.h7[role=listitem]
), its child div.Bk
doesn't have an accessible (but it has a frame), so it is scheduled for re-insertion even though it has descendant accessibles, and recursion stops. When the re-insertion is processed its a no-op because its subtree is already created.
Because we don't recurse down into the other elements we don't remove the div that gets display: none, in my case that is div.adf.ads
.
Assignee | ||
Comment 3•5 years ago
|
||
We need to visit the descendants of a container that has no accessible,
but has accessible children.
Also added a test for delayed removal where we can put all these nasty
cases.
Pushed by eisaacson@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/97923749f8eb Prune or reinsert accessibles in non-accessible container. r=Jamie
Comment 5•5 years ago
|
||
bugherder |
Updated•5 years ago
|
Comment 6•5 years ago
|
||
I can confirm that both Gmail and my banking site are fixed in the latest Nightly build from August 9.
Updated•5 years ago
|
Updated•3 years ago
|
Description
•