1978946 - Re-snapping to points on overflowing snap-area doesn't re-renap to the original position

Status: RESOLVED FIXED

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

Description

[Hiroyuki Ikezoe (:hiro)]

When we aggregate candidate snap point on an overflowing snap area, we use the overflowing element as the snap target id. Thus when we try to re-snap, we use the snap target id element's scroll-snap-align point in preference to the snap point on an overflowing snap area.

For snap points on overflowing snap area we might want to use the position itself rather than the id (= corresponding to an element), but it's still unclear since https://github.com/w3c/csswg-drafts/issues/7438 .

So for now it would be reasonable no to set the id, just to re-evaluate snap candidates without any id.

Comment 1

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1978946 - Do not set any snap target id for candidate snap points on elements larger than the snapport size. r?botond

In Gecko scroll snap id is a raw pointer of each snap target element. So
if the snap target element is larger than the snapport and once after
we snapped to a point inside element but the point is away from the
element's scroll-snap-align point, the snap id forces us to snap to
the element's scroll-snap-align point when we try to re-snap.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/34c2c1c21e7e
https://hg.mozilla.org/integration/autoland/rev/dd0ed736e4df
Do not set any snap target id for candidate snap points on elements larger than the snapport size. r=botond

Comment 3

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/53988 for changes under testing/web-platform/tests

Comment 4

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/dd0ed736e4df

Comment 5

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot