1571327 - aria-activedescendant fails with simultaneous insertion and relocation

Status: RESOLVED FIXED

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

Description

[James Teh [:Jamie]]

Spun off bug 1567377 comment 14.

STR:

1. Open this test case:
   data:text/html,<div tabindex="0" role="combobox" aria-owns="listbox" onkeydown="listbox.hidden = false; this.setAttribute('aria-activedescendant', 'option');"></div><div id="listbox" hidden role="listbox"><div id="option" role="option">option</div></div>
2. Tab to the combo box and press down arrow.
   • Expected: You should get a focus event for the option. (A screen reader should report "option")
   • Actual: You don't. (A screen reader reports nothing.)

I think what's happening is this:

1. The listbox is hidden and thus not in the a11y tree. If you press down arrow at this point, it will simultaneously create the listbox and focus the first item.
2. We see the aria-activedescendant change and schedule DocAccessible::ARIAActiveDescendantChanged.
3. WillRefresh is called.
4. We process insertions. Because aria-owns is present, we don't create the subtree for the listbox. DocAccessible::RelocateARIAOwnedIfNeeded schedules a relocation and returns false when called here: https://searchfox.org/mozilla-central/rev/29cce9a2684ef64c4f1f996087da8b7545d31f65/accessible/base/TreeWalker.cpp#340
5. We process generic notifications, including ARIAActiveDescendantChanged. The subtree for the listbox still doesn't exist, so we fail to get an accessible for the active descendant.
6. Finally, we process relocations. The subtree for the list gets created.. too late!

Moving invalidations/relocations before generic notifications fixes this, but I don't understand this well and I'm concerned it might break other things. All a11y mochitests and browser-chrome tests pass with this change; see try run.

Comment 1

[James Teh [:Jamie]]

Attachment: Bug 1571327: Process generic notifications after relocations to fix aria-activedescendant with simultaneous insertion and relocation.

Previously, if a hidden, aria-owned subtree was shown and aria-activedescendant was simultaneously targeted inside it, aria-activedescendant would fail.
This occurred because when we processed insertions, the presence of aria-owns meant we didn't create the subtree.
This meant that when we processed aria-activedescendant (which occurred before relocations), the active descendant didn't exist yet.
To fix this, we now process generic notifications (including aria-activedescendant) after relocations.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d3b29691bdc6
Process generic notifications after relocations to fix aria-activedescendant with simultaneous insertion and relocation. r=eeejay

Comment 3

[Dorel Luca [:dluca]]

https://hg.mozilla.org/mozilla-central/rev/d3b29691bdc6