Bug 245722 – Smooth scroll in viewport with scroll-snap fails on iOS

• Status: NEW
• Component: Scrolling

[Johannes Odland]

Created attachment 462654 [details]
Video of the test on iOS 16

This bug is a related to https://bugs.webkit.org/show_bug.cgi?id=239063 that was fixed this summer.

It can be triggered on the same test with a slightly different procedure:

element.scrollIntoView() does not work when using `scroll-snap-type: y mandatory` on `:root` in iOS when browser chrome is hidden.

How to replicate: 
1. Open debug view of https://codepen.io/johannesodland/pen/PoEaMWO on iOS Safari 16
2. Click `next` to trigger scrollIntoView (it scrolls to the second section)
3. Click `previous` to trigger scrollIntoView (it scrolls to the first section)
4. Scroll manually to the second section so that url bar / browser chrome is hidden. 
5. Click `previous`

Expected result: The first section should scroll into view

Result on iOS Safari: Nothing happens.

Other browsers and desktop safari works as expected.

[Radar WebKit Bug Importer]

<rdar://problem/100727098>

[Smoley]

Thanks for filing, I've not been able to reproduce this on the latest iOS 16.1 beta (Beta 5 20B5072b). Are still seeing this issue on that build?

[Johannes Odland]

(In reply to Smoley from comment #2)
> Thanks for filing, I've not been able to reproduce this on the latest iOS
> 16.1 beta (Beta 5 20B5072b). Are still seeing this issue on that build?

Not able to test it on beta builds, but the bug is still there in 16.1.

[Johannes Odland]

Bug is still there in Safari 16.2

[Johannes Odland]

Changing title as the bug does not occur in iframes, it occurs when there is scroll-snapping in the main viewport.

eg:
 
```css
html {
  scroll-snap-type: y mandatory;
}

.some-element {
  scroll-snap-align: top;
}
```

```js {
  document.querySelector('.some-element').scrollIntoView({ behavior: "smooth" })  // Fails
}

See https://codepen.io/johannesodland/pen/PoEaMWO and the attached video.
The code-pen must be tested in "debug mode" and not in "edit mode" as it can not be reproduced inside the iframe there.

[Johannes Odland]

Created attachment 464629 [details]
Video of bug in iOS Safari 16.3

scrollIntoView still fails in iOS Safari 16.3. 

It stops working after the browser navigation interface has retracted due to a user scroll. This is similar to the bugs we see with VoiceOver navigation in https://bugs.webkit.org/show_bug.cgi?id=250999 and https://bugs.webkit.org/show_bug.cgi?id=251003

[Simon Fraser (smfr)]

Created attachment 464658 [details]
Test

[Simon Fraser (smfr)]

In working and non-working cases we call PageClientImpl::requestScroll() which starts the animated scroll. But in the bad case, when the Safari UI is collapsed, we immediately call `_updateVisibleContentRects()` to push an update to the web process, and this runs code that re-snaps to the snap point closest to the current scroll position, which kills the animation.

We need to re-think when `_updateVisibleContentRects()` should trigger snapping.

[Johannes Odland]

Could this be the cause of https://bugs.webkit.org/show_bug.cgi?id=251003 as well?

It's a similar bug, but triggered by VoiceOver navigation and not scrollIntoView().

[Johannes Odland]

Thank you for looking into these issues Simon. Do you know if there are any plans to address it in the upcoming 16.4 release?

[Johannes Odland]

I have retested on iOS 16.4 and can confirm that the issue still persists. Element.scrollIntoView({behavior: 'smooth'} fails after the browser interface has been retracted.

I have copied the test case to a new location for easier testing. Here is the URL:
https://johannesodland.github.io/browserbugs/safari-scroll-snap-scroll-into-view-issue.html

[Johannes Odland]

Retested on iOS Safari 16.5: still failing

[Johannes Odland]

Retested on iOS 17
Still fails. 

Programmatic scrolling is still unreliable with scroll snapping on the root/viewport.

[Johannes Odland]

Retested on iOS 17.4. The browser smooth-scrolls to the first section, but then immediately snaps back to the previous snap position.

[Johannes Odland]

Retested on iOS 18.1. Still failing.