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.
<rdar://problem/100727098>
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?
(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.
Bug is still there in Safari 16.2
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.
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
Created attachment 464658 [details] Test
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.
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().
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?
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
Retested on iOS Safari 16.5: still failing
Retested on iOS 17 Still fails. Programmatic scrolling is still unreliable with scroll snapping on the root/viewport.
Retested on iOS 17.4. The browser smooth-scrolls to the first section, but then immediately snaps back to the previous snap position.