Bug 221658 – WKWebView needs to give -scrollView access on macOS

• Component: WebKit API
• Status: NEW

[Jonathan Deutsch]

There's no way to properly control the scroll view for a WKWebView on macOS.  iOS has this; why doesn't the Mac?

The workaround is to inject JavaScript code that uses JavaScript APIs to control the scroll view.  This is clunky and error prone.

There are many different reasons for controlling the scroll view, but ultimately it comes down to being able to create an application that is deeply integrated with web content.  Missing APIs like this are reasons folks will stop producing Mac apps (death by a thousand cuts).

I believe WebView did not provide this either, but it was pretty easy to inspect the view hierarchy and find the scrollview.  This is not possible with WKWebView since it seems to be in another process.

[Tim Horton]

Not quite as easy as it sounds; there is no Cocoa scroll view (no NSScrollView) /at all/ in the current macOS scrolling/compositing model.

Can you be more specific about what you want to do with the scroll view? The answer may not be “expose the scroll view” but possibly “expose API to do X, Y, and Z”, depending on the direction we take with the drawing model, so knowing what X, Y, and Z are could be helpful.

[Jonathan Deutsch]

Created attachment 420229 [details]
Tumult Whisk Scroll Management Injection JS

[Jonathan Deutsch]

In Tumult Hype [https://tumult.com/hype/] scrolling is used all over the place; we will autoscroll to selected items, users will pan the view using the spacebar "hand" gesture, etc. Basically if you are a content editor you need to be in control. The workaround here was to make the WKWebView the maximum calculated size and put it in our own scroll view.

In Tumult Whisk [https://tumult.com/whisk/] have a "scroll sync" feature which keeps the scroll proportion of the editor view the same as the web view. (Clearly not all HTML will render to a proportionate correspondence, but a lot does, so it is useful for users).  The workaround here is javascript injection that receives calls from the app via evaluateJavaScript and sends scroll events via postMessage.  Due to user content changing some of the DOM getters, we have to check for stuff like the document.compatMode and window.visualViewport to manage this correctly. I attached our injection if you're interested.

If a developer's goal like mine is to make a Mac app deeply integrated with web content, they are going to want to control the its viewport. Once they start having to "stuff" their WKWebView with JavaScript workarounds for common tasks, they will question why they are making a native Mac app. I never thought this implementation would be easy, but do think it is important. Thanks!

[Radar WebKit Bug Importer]

<rdar://problem/74423325>