[CTW] Bounds incorrect for scrolled position: fixed/sticky elements which don't get an Accessible; e.g. display: flex
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox111 | --- | fixed |
People
(Reporter: nlapre, Assigned: Jamie)
References
Details
(Whiteboard: [ctw-m5])
Attachments
(1 file)
STR:
- Load the following page:
data:text/html,<div style="display:flex; bottom:0px; right:0px; position:fixed;"><button>testing</button></div><script> for (let i = 0; i < 1000; ++i) { const div = document.createElement("div"); div.innerHTML = `<button>${i}</button>`; document.body.append(div); } </script>
- Examine the bounds of the "testing" button's accessible.
- Scroll down the page to the bottom.
- Re-examine the bounds of the same button, as in step 2.
Expected results: The bounds in step 4 are the same as in step 2.
Actual results: The y-coordinate of the bounds in step 4 is very negative.
This is the simplified version of the twitter "Don’t miss what’s happening" bottom bar that appears when you're not signed in. I suspect it also explains what is going on in Bug 1814299, but need to confirm.
Note that I tested this on a version of Nightly (and a developer build, to be sure) that included the fix from Bug 1809836. It seems like display: flex adds another layer of complication here.
Assignee | ||
Comment 1•2 years ago
|
||
ARRRRRGGGGHHH!
This occurs because the div with display: flex doesn't get an Accessible. If you give it an id or a role, it gets an Accessible and the problem magically goes away.
Assignee | ||
Comment 2•2 years ago
|
||
We're going to need something similar to bug 1806356 (transforms) but for position: fixed.
Assignee | ||
Comment 3•2 years ago
|
||
We'll need to get bug 1806356 finished before we try to properly patch this. Otherwise, we will almost certainly end up with annoying merge conflicts.
Assignee | ||
Comment 4•2 years ago
|
||
I've written a browser test for this, so I'll finish the patch once I'm unblocked.
Assignee | ||
Comment 5•2 years ago
|
||
We need to know about position: fixed in the parent process a11y cache, so we always need an Accessible for such elements.
Previously, we calculated bounds incorrectly if a position: fixed element wasn't included in the a11y tree.
Assignee | ||
Comment 6•2 years ago
|
||
We'll likely also need to deal with this for position: sticky.
Assignee | ||
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Pushed by jteh@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/24887c751247 Force Accessible creation if an element has position: fixed/sticky. r=nlapre
Comment 8•2 years ago
|
||
bugherder |
Description
•