Bug 218465 – iOS VisualViewport scroll events fire only when scrolling finishes

• Status: NEW
• Component: Scrolling

[Darryl Pogue]

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.

[Darryl Pogue]

Test case: https://jsfiddle.net/5kgxab17/

[Radar WebKit Bug Importer]

<rdar://problem/71046513>

[Simon Fraser (smfr)]

I'm not sure how to interpret the tescase. Darryl, could you make it clearer?

[Simon Fraser (smfr)]

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.

[Darryl Pogue]

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.

[Peter Wiebe]

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.

[Darryl Pogue]

Pull request: https://github.com/WebKit/WebKit/pull/29531