Bug 1758689 Comment 1 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Implementing hit testing properly using the cache is going to be a very difficult challenge. To enable us to ship sooner, an interim solution could be that we still do hit testing synchronously, but with a short timeout (100 ms?) to prevent deadlocks or long freezes. That has the least chance of regressions, but is very ugly and doesn't get us to our goal of avoiding all sync a11y calls to content. Even so, I suspect hit testing isn't used by things other than screen readers and magnifiers, so this is maybe acceptable for now.

Another possibility is to do something similar to Chromium. It dispatches an async hit test, but then falls back to walking the a11y subtree and checking if the coordinate is inside the bounds of each node. The fallback isn't accurate for complex layout involving z-index, overflow, etc. The next time a hit test query is received, if the rect from the last async hit test matches, it will return that node. The idea is that the first hit test might be inaccurate, but subsequent hit tests within the same node will be more accurate.
Implementing hit testing properly using the cache is going to be a very difficult challenge. To enable us to ship sooner, an interim solution could be that we still do hit testing synchronously, but with a short timeout (100 ms?) to prevent deadlocks or long freezes. That has the least chance of regressions, but is very ugly and doesn't get us to our goal of avoiding all sync a11y calls to content. Even so, I suspect hit testing isn't used by things other than screen readers and magnifiers, so this is maybe acceptable for now.

Another possibility is to do something similar to Chromium. It dispatches an async hit test, but then falls back to walking the a11y subtree and checking if the coordinate is inside the bounds of each node. The fallback isn't accurate for complex layout involving z-index, overflow, etc. The next time a hit test query is received, if the rect from the last async hit test matches, it will return that node. The idea is that the first hit test might be inaccurate, but subsequent hit tests within the same node will be more accurate.

Aside from the initial inaccuracy, one potential concern with this second solution is retrieving the bounds for every Accessible. Because we walk the ancestors to calculate bounds, this tree walk would end up being O(n^2). I guess only profiling will tell us how much that matters on large pages.

Back to Bug 1758689 Comment 1