Open Bug 1683130 Opened 4 years ago Updated 4 years ago

overscroll behaviour has no effect on elements with no overflow

Categories

(Core :: Panning and Zooming, defect, P3)

Firefox 84
defect

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.

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.

Flags: needinfo?(james.campbell)
Attached file elements.html
Flags: needinfo?(james.campbell)

I've attached elements.html

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.

Status: UNCONFIRMED → NEW
Component: Untriaged → Layout: Scrolling and Overflow
Ever confirmed: true
Product: Firefox → Core
Component: Layout: Scrolling and Overflow → Panning and Zooming

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:

  1. Activate scroll frames with no overflow but which have non-default overscroll-behavior.
  2. 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.

Severity: -- → S3
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: