Overscroll transform should not apply to fixed content
Categories
(Core :: Panning and Zooming, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox103 | --- | fixed |
People
(Reporter: botond, Assigned: dlrobertson)
References
(Blocks 3 open bugs, Regressed 1 open bug)
Details
Attachments
(3 files, 2 obsolete files)
Based on the direction in this spec issue, we should update our overscroll implementation such that the overscroll transform does not apply to position:fixed content.
|
Reporter | |
Comment 1•3 years ago
|
||
From an implementation point of view this will largely be a backout of bug 1704503.
|
Assignee | |
Comment 2•3 years ago
|
||
After reading this comment I'm struggling to see how our current behavior is incorrect.
fixed-position elements whose scroller is not their containing block do not participate in overscroll
So this would mean that in the example provided in bug 1704503 when scrolling in the outer frame the outer red box would be subject to the overscroll transform, but when scrolling on the inner frame the inner green box would be subject to the overscroll transform while the outer would not. This is what I see when I tinker with the test given. Chrome doesn't apply the overscroll transform to the fixed element in the innter box when attempting to overscroll this box, while Safari does what we do.
|
|
Reporter | |
Comment 3•3 years ago
|
||
(In reply to Dan Robertson (:dlrobertson) from comment #2)
fixed-position elements whose scroller is not their containing block do not participate in overscroll
So this would mean that in the example provided in bug 1704503 when scrolling in the outer frame the outer red box would be subject to the overscroll transform, but when scrolling on the inner frame the inner green box would be subject to the overscroll transform while the outer would not.
Yeah, it takes a bit of untangling of spec language to understand what this means.
Note, this part: "when scrolling on the inner frame ... the outer [red box] would not [be subject to the overscroll transform]" was never in question. The outer red box is not a child of the inner scrollframe, so there's no possible expectation that scrolling or overscrolling the inner scrollframe moves it in any way.
The interesting questions are:
- Does overscrolling the outer scrollframe (<html> element) affect the red box?
- Does overscrolling the inner scrollframe (<div> element) affect the green box?
Let's work through the spec language to answer these.
fixed-position elements whose scroller is not their containing block do not participate in overscroll
The phrasing suggests every fixed element has a scroller, and a containing block.
A fixed element's scroller is, presumably, the scrollable element that would normally scroll it if it were not fixed. That is, in this test case, the red box's scroller is the <html>, and the green box's scroller is the <div>.
What about the containing block? Looking at the MDN docs, there are two possibilities for a fixed element's containing block:
- the viewport of the enclosing document
- the nearest ancestor element that has certain properties such as
transform
The green box falls into the second case (it has a transformed ancestor), while the red box falls into the first.
Finally, in which cases is the containing block the same as the scroller?
- Green box: containing block and scroller are both the scrollable div
- Red box: containing block is the viewport, which is different from the root scroller (<html>). This point is a bit subtle: the viewport is considered to be outside the root scroller; this is how we model the distinction between content that's positioned relative to the viewport (fixed to the viewport/screen) vs. positioned relative to the document origin (scrolled by the root scroller).
==> I believe the spec is saying the green box should participate in overscroll (when its scroller, the <div>, is scrolled), but the red box should not participate in overscroll (when its scroller, the <html>, is scrolled).
|
|
Assignee | |
Comment 4•3 years ago
|
||
(In reply to Botond Ballo [:botond] from comment #3)
fixed-position elements whose scroller is not their containing block do not participate in overscroll
The phrasing suggests every fixed element has a scroller, and a containing block.
A fixed element's scroller is, presumably, the scrollable element that would normally scroll it if it were not fixed. That is, in this test case, the red box's scroller is the <html>, and the green box's scroller is the <div>.
What about the containing block? Looking at the MDN docs, there are two possibilities for a fixed element's containing block:
- the viewport of the enclosing document
- the nearest ancestor element that has certain properties such as
transformThe green box falls into the second case (it has a
transformed ancestor), while the red box falls into the first.Finally, in which cases is the containing block the same as the scroller?
- Green box: containing block and scroller are both the scrollable div
- Red box: containing block is the viewport, which is different from the root scroller (<html>). This point is a bit subtle: the viewport is considered to be outside the root scroller; this is how we model the distinction between content that's positioned relative to the viewport (fixed to the viewport/screen) vs. positioned relative to the document origin (scrolled by the root scroller).
==> I believe the spec is saying the green box should participate in overscroll (when its scroller, the <div>, is scrolled), but the red box should not participate in overscroll (when its scroller, the <html>, is scrolled).
Thanks so much for the detailed response! Had to read this a few times, but this finally makes a lot of sense and I see where my view of how things should work was off.
(From the MDN docs)
Many developers believe that the containing block of an element is always the content area of its parent, but that isn't necessarily true. Let's investigate the factors that determine what an element's containing block is.
I seem to have fallen into this trap.
|
|
Assignee | |
Comment 5•3 years ago
|
||
Would this be a good bug to include a test case in the web-platform-tests? If possible, I'd like to add one to make sure I implement it right.
|
|
Assignee | |
Updated•3 years ago
|
|
|
Reporter | |
Comment 6•3 years ago
|
||
(In reply to Dan Robertson (:dlrobertson) from comment #5)
Would this be a good bug to include a test case in the web-platform-tests? If possible, I'd like to add one to make sure I implement it right.
It's definitely a good idea to have test coverage for this.
Unfortunately, I don't think web-platform-tests have the necessary infrastructure to trigger overscrolling in a test. (That could be interesting to add, but probably shouldn't block this work.)
Rather, we currently test overscroll using using our reftest framework. We have an existing set of tests for it, which we can modify or expand as needed.
|
|
Assignee | |
Comment 7•3 years ago
|
||
|
|
Reporter | |
Comment 8•3 years ago
|
||
|
|
Reporter | |
Comment 9•3 years ago
|
||
|
|
Assignee | |
Comment 10•3 years ago
|
||
When transforming the hit test to what gecko expects, ensure that we
handle fixed elements correctly.
Depends on D146825
|
|
Assignee | |
Comment 11•3 years ago
|
||
When a hit test result hits a fixed element that extends over the gutter, do not
absorb the event.
Depends on D148076
|
||
Updated•3 years ago
|
|
|
||
Updated•3 years ago
|
|
||
Comment 12•3 years ago
|
||
|
||
Comment 13•3 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/89b94e41ab14
https://hg.mozilla.org/mozilla-central/rev/87c318aed85b
https://hg.mozilla.org/mozilla-central/rev/c6e364c416d7
|
|
Reporter | |
Updated•3 years ago
|
Description
•