scroll gets handed off from `position: fixed` element to container
Categories
(Core :: Panning and Zooming, defect, P3)
Tracking
()
People
(Reporter: 709922234, Assigned: dlrobertson)
References
()
Details
(Keywords: correctness, Whiteboard: [gfx-noted])
Attachments
(7 files)
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:56.0) Gecko/20100101 Firefox/56.0 Build ID: 20170708030206 Steps to reproduce: 1. open https://codepen.io/mantou132/pen/MoPrYZ 2. scroll list Actual results: <main> element scroll Expected results: <main> element not scroll
Comment 2•7 years ago
|
||
I reproduce the same behaviour in 54 all the way back to 45 and current nightly. So it doesn't seem that anything changed. I'm guessing this is probably because the scroll ancestor of the fixed pos content is the root scroll frame. In this case we shouldn't be scrolling the root scroll frame because it's overflow hidden.
Updated•7 years ago
|
Comment 3•7 years ago
|
||
(In reply to Timothy Nikkel (:tnikkel) from comment #2) > I reproduce the same behaviour in 54 all the way back to 45 and current > nightly. So it doesn't seem that anything changed. What I'm seeing is that with APZ, scroll is handed off from the <dialog> element to the <main> element, but without APZ, it's not. So APZ has changed the scroll handoff behaviour. > I'm guessing this is probably because the scroll ancestor of the fixed pos > content is the root scroll frame. In this case we shouldn't be scrolling the > root scroll frame because it's overflow hidden. The thing that the scroll is being handed off to is the <main> element, not the RSF. The <main> element is overflow:auto, so scroll handoff targeting it is expected. The question, then, is why the scroll _wasn't_ handed off pre-APZ. My guess is it has to do with the <dialog> being position:fixed.
Updated•7 years ago
|
Comment 4•7 years ago
|
||
Neither Chrome nor Safari do the handoff so this is likely a Firefox (and therefore APZ) bug.
This property can solve the problem https://bugzilla.mozilla.org/show_bug.cgi?id=951793
Comment 6•7 years ago
|
||
(In reply to 709922234 from comment #5) > This property can solve the problem > > https://bugzilla.mozilla.org/show_bug.cgi?id=951793 It can be used as a workaround, yes. However, it looks like there is a bug in our default behaviour, and that should be fixed too (which is what this bug tracks).
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 7•2 years ago
|
||
Updated•2 years ago
|
Comment 8•2 years ago
|
||
Bug 1693451 (which has a prototype patch by Timothy attached to it) might be relevant here.
Assignee | ||
Comment 9•2 years ago
|
||
Depends on D148662
Comment 10•2 years ago
|
||
Comment 11•2 years ago
|
||
Comment 12•2 years ago
|
||
Comment 13•2 years ago
|
||
I attached some testcases to help us think through the various considerations here and arrive at a correct fix.
Brief descriptions:
Testcase 1
This is basically a simplified version of the testcase in the original report. The important features are:
- the fixed element is itself a scroll frame
- the fixed element has an ancestor (in the DOM) which is scrollable but isn't the <html>
Testcase 2
This is like testcase 1, but the fixed element's scrollable ancestor is the <html>.
Testcase 3
This is like testcase 1, but the fixed element itself isn't a scroll frame; rather, it contains a scroll frame descendant (and we're interested in the handoff behaviour of that descendant).
Comment 14•2 years ago
|
||
Now comparing the behaviour on the three testcases:
Chrome | Firefox (status quo) | Firefox (with current patch) | |
---|---|---|---|
Testcase 1 | no handoff | handoff | no handoff |
Testcase 2 | handoff | handoff | no handoff |
Testcase 3 | no handoff | handoff | handoff |
If we take Chrome's behaviour as the desired state, then the current patch fixes testcase 1 as intended, but it breaks testcase 2 (prevents handoff to the root when it shouldn't), and does not fix testcase 3 (it only handles the case where the fixed element is itself a scroll frame).
Comment 15•2 years ago
•
|
||
Here's the conceptual model behind the desired behaviour: when an element is fixed, it's taken "out of flow", and, in the frame tree, becomes a descendant of the viewport rather than a descendant of (the frame for) its in-flow (DOM) ancestor.
Scroll handoff is intended to follow the relationships in the frame tree, which is why we should not hand off from a fixed element (or its descendants) to its non-root DOM ancestors, but should still hand off from a fixed element to the viewport (root).
Assignee | ||
Comment 16•2 years ago
|
||
(In reply to Botond Ballo [:botond] from comment #15)
Here's the conceptual model behind the desired behaviour: when an element is fixed, it's taken "out of flow", and, in the frame tree, becomes a descendant of the viewport rather than a descendant of (the frame for) its in-flow (DOM) ancestor.
Scroll handoff is intended to follow the relationships in the frame tree, which is why we should not hand off from a fixed element (or its descendants) to its non-root DOM ancestors, but should still hand off from a fixed element to the viewport (root).
Ah! This is very helpful!
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Comment 17•2 years ago
|
||
The following patch is waiting for review from an inactive reviewer:
ID | Title | Author | Reviewer Status |
---|---|---|---|
D149925 | Bug 1379458 - The ScrollParentId should match the ASR tree. r=tnikkel | dlrobertson | botond: Back Aug 13, 2022 |
:dlrobertson, could you please find another reviewer?
For more information, please visit auto_nag documentation.
Comment 18•2 years ago
|
||
Bad bot, that doesn't make sense, he's just on PTO.
Assignee | ||
Comment 19•2 years ago
|
||
Remove the unused SCROLLABLE_FOLLOW_OOF_TO_PLACEHOLDER flag now that ASRs should
match the mScrollParentId.
Depends on D149925
Updated•2 years ago
|
Comment 20•2 years ago
|
||
Pushed by drobertson@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/e1347c761038 Add test group for overscroll handoff. r=botond https://hg.mozilla.org/integration/autoland/rev/54494d5e152c The ScrollParentId should match the ASR tree. r=botond,tnikkel,mstange https://hg.mozilla.org/integration/autoland/rev/1d37427ef6f2 Remove the unused SCROLLABLE flag. r=botond
Comment 21•2 years ago
|
||
Backed out for causing reftest failures on nsDisplayList.cpp
- Backout link
- Push with failures
- Failure Log
- Failure line: Assertion failure: false (item should have finite clip with respect to aASR), at /builds/worker/checkouts/gecko/layout/painting/nsDisplayList.cpp:2662
Assignee | ||
Comment 22•2 years ago
|
||
(In reply to Cristian Tuns from comment #21)
Backed out for causing reftest failures on nsDisplayList.cpp
- Backout link
- Push with failures
- Failure Log
- Failure line: Assertion failure: false (item should have finite clip with respect to aASR), at /builds/worker/checkouts/gecko/layout/painting/nsDisplayList.cpp:2662
Ran a ton of tests today, and I've yet to see the failure linked in any of the try pushes or local tests. I could be wrong, but I think the failure linked was due to https://hg.mozilla.org/integration/autoland/rev/4dfea46f3cd01c2134c9f1034136e3a065cc81cd. I'm going to re-land the change. Please back out the patch if I've misunderstood something.
Comment 23•2 years ago
|
||
Pushed by drobertson@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/61a605c335b0 Add test group for overscroll handoff. r=botond https://hg.mozilla.org/integration/autoland/rev/3239f01e81d7 The ScrollParentId should match the ASR tree. r=botond,tnikkel,mstange https://hg.mozilla.org/integration/autoland/rev/dd6888957eff Remove the unused SCROLLABLE flag. r=botond
Comment 24•2 years ago
|
||
Backed out 1 changesets (Bug 1379458) for causing devtools failures on nsGfxScrollFrame.cpp.
Backout link
Push with failures <--> dt2
Failure Log
Assignee | ||
Comment 25•2 years ago
|
||
(In reply to Marian-Vasile Laza from comment #24)
Backed out 1 changesets (Bug 1379458) for causing devtools failures on nsGfxScrollFrame.cpp.
Backout link
Push with failures <--> dt2
Failure Log
Thanks! It appears there is a bug in AutoCurrentActiveScrolledRootSetter::SetCurrentScrollParentId
, where we set mCanBeScrollParent
when we shouldn't. I think this can be fixed by ensuring that mOldScrollParentId
is the old mBuilder->mCurrentScrollParentId
when the setter is called.
Comment 26•2 years ago
|
||
Backed out the two remaining changesets.
Backout link: https://hg.mozilla.org/integration/autoland/rev/ba1c8aa8d54e71238f3e5dfac303d3ae44adef59
Failure log: https://treeherder.mozilla.org/logviewer?job_id=394832861&repo=autoland&lineNumber=38534
Updated•2 years ago
|
Assignee | ||
Comment 27•2 years ago
|
||
I figured out the cause of us hitting the assert, but I've got some more testing to do before I push the change for review.
Comment 28•1 year ago
|
||
Pushed by drobertson@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/f94a03948385 Add test group for overscroll handoff. r=botond https://hg.mozilla.org/integration/autoland/rev/58f50284310b The ScrollParentId should match the ASR tree. r=botond,tnikkel,mstange https://hg.mozilla.org/integration/autoland/rev/4681951d59b7 Remove the unused SCROLLABLE flag. r=botond
Comment 29•1 year ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/f94a03948385
https://hg.mozilla.org/mozilla-central/rev/58f50284310b
https://hg.mozilla.org/mozilla-central/rev/4681951d59b7
Updated•1 year ago
|
Comment 30•1 year ago
|
||
Reproduced the issue on Firefox 70.0 on macOS 13.1 by following the STR from Comment 0 and the testcases provided by Botond.
The behaviors are now as follows on Firefox 110.0b3:
- TC from original post has no handoff
- Testcase 1 and 3 has no handoff
- Testcase 2 has the handoff
Tests were performed on macOS 13.1, Windows 11 and Ubuntu 22.04.
Updated•1 year ago
|
Updated•1 year ago
|
Description
•