Don't recreate accessible when an ancestor becomes visibility: hidden
Categories
(Core :: Disability Access APIs, enhancement)
Tracking
()
People
(Reporter: Jamie, Unassigned)
References
Details
STR:
- Open this test case:
data:text/html,<div id="a" title="a"><p id="b" style="visibility: visible;">p</p><button onclick="a.style.visibility = 'hidden';">hide a - Get the Accessible for "p".
- Press the "hide a" button.
- Get the Accessible for "p".
- Expected: The Accessibles should be the same (no re-creation).
- Actual: The Accessible is different to that retrieved in step 2 (re-creation).
Bug 686400 prevented layout frame reconstruction from re-creating Accessibles. However, we still re-create in the CSS visibility case.
This occurs because layout explicitly removes visibility: hidden elements from the a11y tree. A11y still needs to be notified about these changes, but we should use our PruneOrInsertSubtree code to figure out what to do with them, rather than removing them unconditionally.
We can probably fix this by having RestyleManager call a11y's ContentRangeInserted notification rather than ContentRemoved. The naming is weird, though.
|
Reporter | |
Comment 1•3 years ago
|
||
Blah. Making the change in RestyleManager doesn't help because PruneOrInsertSubtree can't actually handle removing an ancestor while still keeping descendants. It calls ContentRemoved itself, and even though we then walk the subtree to reinsert nodes, they're already detached at that point (no longer in mNodeToAccessibleMap because of UncacheChildrenInSubtree), so nothing gets reused.
We'd need to find some way to fix this in PruneOrInsertSubtree first.
|
|
Reporter | |
Comment 2•3 years ago
|
||
Apparently past me already filed this exact bug and forgot about it.
Description
•