Closed Bug 1312165 Opened 6 years ago Closed 4 months ago

Implement 'scroll-snap-stop'


(Core :: CSS Parsing and Computation, enhancement, P3)

52 Branch



103 Branch
Tracking Status
firefox52 --- wontfix
firefox103 --- fixed


(Reporter: sebo, Assigned: hiro)


(Blocks 2 open bugs, )


(Keywords: dev-doc-complete, Whiteboard: [layout:backlog], [wptsync upstream])


(5 files)

The latest CSS Scroll Snap spec. defines a 'scroll-snap-stop' property defining whether the scroll container must stop at each snap position it passes, or may pass multiple snap positions before coming to rest.

This property should be implemented accordingly.

Keywords: dev-doc-needed
Too late for firefox 52, mass-wontfix.
Blocks: css3test
Priority: -- → P3
This feature is marked at-risk in the latest draft.
Type: defect → enhancement

FWIW, the feature was marked at risk due to lack of implementation interest. But we (at Chromium) have implemented and plan to ship it soon as well. I have let the spec editors know this quite a while back but thought to mention it here as well.

This is mainly because we have heard from several developers (e.g., AirBnb, AMP) that they want this. A particular popular usecase is to create full-size image carousels that only snap to the next image (e.g., similar to how native apps do such things). This is exactly why this was in the spec in the first place. Normally a fling gesture snaps to the closest area near its "natural end point" which is not the right behavior in such usecases.

We have added one wpt test as well for this feature:

Are you able to tell me if Firefox plans to implement this feature at all? Or do you have objections to having it in the specification?. I like to include this information in my blink intent-to-ship [1] if possible.


Emilio, do you know who would be able to answer the questions above? Or should those just go to ?

Flags: needinfo?(emilio)

I am planing to implement this but not soonish because the code will be really messy without dropping the code for the old scroll snap feature (bug 1218264, bug 1218265 and more cleanup). So my current plan is

  1. Ship the new scroll snap type in 68 (I mean 68 as a release)
  2. Drop the old implementation entirely
  3. Cleanup the code
  4. Implement scroll-snap-stop

Yeah, Hiro / Botond are better to reply to that question :)

Flags: needinfo?(emilio)
Whiteboard: [layout:backlog]

Is this still not implemented?

I'm not sure if I'm hallucinating, but it seems to work in my firefox nightly 84.0.2 (64-bit)

The scroll-snap-stop property is not implemented yet, though most of the others parts of the CSS Scroll Snap specification. See also bug 1231777.

For what it's worth, Chromium already implemented it, though it doesn't work as expected. Therefore I've filed


PS: 84.0.2 is the current stable version of Firefox, Nightly is at 86.0a1.

The scroll-snap-stop property works quite well on Chromium/Safari as of today. The whole scroll-snap feature is quite useless if the stop is not implemented, at least if you have more than two sections. Are there any news about this issue?

Hi :hiro! Do you have plans to work on that?

Flags: needinfo?(hikezoe.birchill)

Yep, We have a plan to work on this in this H2 (or H1 if it's possible).

Flags: needinfo?(hikezoe.birchill)

I have a need for this right now. Use case is a responsive horizontal carousel, with items having varied widths.

On various devices/browsers, scroll snap with organic scroll interactions (ie touch swipes, mousewheel left/right, etc).

The carousel also has visible left/right arrows for alternative navigation (mainly used by desktop users). On clicking an arrow once, I simply need to programmatically scroll to the next available snap point (whatever it is). This is easily done using scrollBy(<some-huge-amount-like-3000px>) and letting scroll-snap-stop stop the scroll at the next snap point (usually like 300px). It works great in Chrome and other browsers, and saves me from having to do a bunch of extra work in JS.

In Firefox, this does not work. Instead I'll have to feature-detect and give Firefox users a lesser experience (no snapping when clicking left/right arrows). The alternative is a mess of JS functions to track exact scroll position relative to items (stuff we did 10 years ago).

See Also: → 1766192

I've started working on this. But before doing this, we have to fix/change our implementation such as bug 1766192.

Assignee: nobody → hikezoe.birchill
Depends on: 1766805

In our scroll snap implementation, there's a special handling on a page
scrolling that the closest snap point in the same page before scrolling is prior
to the closest snap point in the next page. There was no test case to test the

Depends on D145851

If the content is auto scaling down, the document.scrollingElement is not

Attachment #9275669 - Attachment description: Bug 1312165 - Honor `scroll-snap-stop: always`. r?botond → WIP: Bug 1312165 - Honor `scroll-snap-stop: always`. r?botond
Attachment #9275669 - Attachment description: WIP: Bug 1312165 - Honor `scroll-snap-stop: always`. r?botond → Bug 1312165 - Honor `scroll-snap-stop: always`. r?botond

Will land after this softfreeze cycle finished.

Flags: needinfo?(hikezoe.birchill)
Pushed by
Add a mochitest to make sure our special handling for page down/up scrolls. r=botond
Add a meta viewport to avoid auto scaling down the content in scroll-snap-stop-change.html. r=botond
Parse scroll-snap-stop style and propagate it to APZ side. r=emilio,botond
Rewrite CalcSnapPoints::AddEdge with switch statement. r=botond
Honor `scroll-snap-stop: always`. r=botond
Created web-platform-tests PR for changes under testing/web-platform/tests
Whiteboard: [layout:backlog] → [layout:backlog], [wptsync upstream]
Regressions: 1771835
Regressions: 1771836
Upstream PR merged by moz-wptsync-bot
Flags: needinfo?(hikezoe.birchill)

"Firefox 103 for developers" doc has been updated here: Doc issue tracker for this work is here:

You need to log in before you can comment on or make changes to this bug.