Closed Bug 1585317 Opened 10 months ago Closed 9 months ago

Scroll anchoring ignores scroll-padding

Categories

(Core :: Layout: Scrolling and Overflow, defect, P3)

69 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla71
Tracking Status
firefox71 --- fixed

People

(Reporter: tomapaunovic, Assigned: emilio)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36

Steps to reproduce:

  • Enable layout.css.scroll-anchoring.highlight
  • Set scroll-padding-top to non-zero value on html and body tag
  • Verify it's working by executing scrollIntoView to some element -> you should see offset equal to scroll-padding-top
  • Scroll anchoring is still anchoring from top of the viewport

This is contrary to CSS-Scroll-Anchoring specification since scroll-padding-top should modify "optimal viewing region" which scroll anchoring uses to determine eligible anchor nodes. More details

https://drafts.csswg.org/css-scroll-anchoring/#anchor-node-selection
https://drafts.csswg.org/css-scroll-snap-1/#optimal-viewing-region

Actual results:

Scroll anchoring is still trying to anchor on elements on top of viewport, regardless of scroll-padding value, while scrollIntoView works as expected. So if I combine scroll-padding with scrollIntoView and some dom changes (elements collapsing etc) I get unwanted scroll jumping.

Expected results:

Optimal viewing region should be modified by scroll-padding and scroll anchoring should use that area. For example, if we have scroll-padding-top: 100px, scroll anchoring should not anchor elements that are in the top 100 pixels of the viewport.

In other words, if there is a fixed navbar on top of the viewport and scroll-padding-top is set to the height of the navbar, then scroll anchoring should anchor elements right below the navbar as opposed to elements on top of the viewport (which are under navbar).

CSS-Scroll-Anchoring specification specifies that scroll-padding-top should modify "optimal viewing region" which scroll anchoring uses to determine eligible anchor nodes. More details

https://drafts.csswg.org/css-scroll-anchoring/#anchor-node-selection
https://drafts.csswg.org/css-scroll-snap-1/#optimal-viewing-region

Component: Untriaged → Layout: Scrolling and Overflow
Product: Firefox → Core
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3

Ryan, what was the reasoning for using the visual viewport rather than the scrollport for the root? Spec only says to use the scrollport (blink uses yet a different thing, I think, but it seems to be the layout viewport... Also doesn't seem to account for scroll-padding).

It would've been nice to have a test for bug 1518640. Or a spec change proposal, maybe...

Reason is that scroll-padding percentages are resolved against the scrollport size... Not opposed of having them resolve against a different thing here, but it's not clear what is the right thing to do here...

Should we just switch back to use the layout viewport and account for scroll-padding? Or something else?

Flags: needinfo?(rhunt)

Unclear whether the visual viewport code path is the right thing to do at all.

Bug 1518640 was motivated by some negative experiences I had with local debugging of a test case. It probably slipped my mind that the spec was referring to the layout viewport there. Although I don't know what level the visual viewport is specified yet anywhere either. So I'd lean towards matching Chrome's behavior here if possible.

And the reason scroll-padding isn't accounted for is because it didn't exist when scroll-anchoring was implemented, it wasn't an oversight.

Flags: needinfo?(rhunt)

I recall having a conversation with Ryan about bug 1518640 and concluding that the visual viewport is the closer fit for what scroll anchoring is trying to accomplish conceptually.

Scroll anchoring is trying to make sure that the content you are looking at remains on-screen in the face of changes like content above loading or screen rotation. If you're zoomed in, the visual viewport is what's actually on-screen, so it makes sense to use an anchor inside the visual viewport. Otherwise, scroll anchoring could actually cause what's in the visual viewport to shift, such as in the scenario described in bug 1518640 comment 0.

I don't think it's clear that "scrollport" in a spec refers to the layout viewport in preference to the visual viewport. I think most specs gloss over the distinction. For a long time (prior to bug 1423011), our "scrollport" effectively was the visual viewport on mobile.

Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c10147827a4f
When using the scrollport, account for scroll-padding for anchor node selection. r=botond
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/19472 for changes under testing/web-platform/tests
Pushed by emilio@crisal.io:
https://hg.mozilla.org/integration/autoland/rev/a49132352f5b
follow-up: Rename a test so that it doesn't collide with css/css-scroll-snap/scroll-padding.html. r=me CLOSED TREE
Flags: needinfo?(emilio)
Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.
Status: NEW → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla71
Assignee: nobody → emilio
Upstream PR merged by moz-wptsync-bot
Flags: qe-verify+

Removing qe-verify+ from this bug since it's covered by automated test.

Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.