Closed Bug 1571616 Opened 5 years ago Closed 5 years ago

Broken accessibility tree when expanding a Gmail conversation

Categories

(Core :: Disability Access APIs, defect, P1)

defect

Tracking

()

RESOLVED FIXED
mozilla70
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:

  1. Open a Gmail conversation containing more than one message.
  2. Press ; (semi-colon) to expand the conversation.
  3. Press p to focus the first message.
  4. Press shift+f10 to open the context menu, then choose Inspect Accessibility Properties.
  5. Expand the listitem, then the section.
  6. Count the children of the section.
    • Expected: 4.
    • Actual: 5.
  7. 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.
  8. Select the first grouping child of the section.
  9. 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?

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.

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.

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
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70
Assignee: nobody → eitan

I can confirm that both Gmail and my banking site are fixed in the latest Nightly build from August 9.

Blocks: 1572490
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: