WKWebView on iOS dispatches scroll events on the scrollingElement as it is scrolling, which allow animations and element positioning to be updated as the scroll happens. The visualViewport seems to only dispatch scroll events when the scrolling has come to a stop, even when using passive event listeners. When using visualViewport to adjust elements on screen to avoid the iOS keyboard overlay, this results in janky updates to element position.
Test case: https://jsfiddle.net/5kgxab17/
<rdar://problem/71046513>
I'm not sure how to interpret the tescase. Darryl, could you make it clearer?
The VisualViewport only fires 'scroll' events when the visual viewport changes relative to the layout viewport. That only happens when zoomed, and possibly when some resizing because of the keyboard happen.
Created attachment 430226 [details] iOS Test Case (In reply to Simon Fraser (smfr) from comment #3) > I'm not sure how to interpret the tescase. Darryl, could you make it clearer? Hi Simon, I've put together a clearer test case for iOS that demonstrates the problem. GitHub: https://github.com/dpogue/webkit-bug-218465-testcase Source with Xcode project also attached as a zip file.
If you compare the values of window.scrollY and window.visualViewport.offsetTop in an window.onscroll event handler the offsetTop values typically do not update until after the scroll motion completes, whereas the window.scrollY values update continuously throughout the scrolling motion. This makes the scroll event handler much less useful and work in an unexpected way.