overscroll behaviour has no effect on elements with no overflow
Categories
(Core :: Panning and Zooming, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox84 | --- | affected |
People
(Reporter: james.campbell, Unassigned)
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36
Steps to reproduce:
Create an element with "overflow: scroll; overscroll-behaviour: contain" but without any content that overflows
Actual results:
The the scrolling stacking isn't contained meaning there is no way to prevent the entire scrollview from moving without forcing the content of the container element to always be taller than the container.
Expected results:
There should be a way to indicate to the browser that we do not want scroll stacking to happen even when the content of a container doesn't overflows.
Comment 1•4 years ago
|
||
Hi James,
I see that you have loaded three similar bugs. I'll like to take a look at all of them, but could you attach me a test case like it was done in this bug, please? https://bugzilla.mozilla.org/show_bug.cgi?id=1576010 . Or could you share the URL to codepen where I could test this?
Thanks in advance, Flor.
Reporter | ||
Comment 2•4 years ago
|
||
Reporter | ||
Comment 3•4 years ago
|
||
I've attached elements.html
Comment 4•4 years ago
|
||
Hi,
Thanks for the details. I was able to reproduce the bug on Windows 10 on FF84. I believe that the severity is S4 or S3. I've chosen a component. If you consider that there's another component that's more proper for this case you may change it.
Best regards, Flor.
Updated•4 years ago
|
Comment 5•4 years ago
|
||
Thanks for the report.
Yes, this is an artifact of overscroll-behavior's implementation in the compositor. The overscroll-behavior information is stored in ScrollMetadata
which is only created for active scroll frames. Scroll frames that don't actually have overflow never become active, and so overscoll-behavior info for them is never sent to the compositor.
Possible approaches to fixing this:
- Activate scroll frames with no overflow but which have non-default overscroll-behavior.
- Re-work how overscroll-behavior information is communicated to the compositor. Instead of storing it in
ScrollMetadata
, store it in the compositor hit-test flags.
Both of these are going to have performance impacts (in the first case, more active scroll frames ==> more APZCs and associated metadata; in the second case, larger display lists due to more compositor hit test items), though the impact is going to be limited to cases where overscroll-behavior
is actually used. Still a potential concern if e.g. some widely used style library ends up using overscroll-behavior
as a default style on many things.
Description
•