Bug 182710 – WKWebView window.scrollTo() scrolls to wrong position depending on contentInsetAdjustmentBehavior setting

• Status: NEW
• Component: Scrolling

[Zach Waugh]

Created attachment 333635 [details]
Sample project

When a WKWebView on iOS 11 uses the default `contentInsetAdjustmentBehavior`, then calls to `window.scrollTo()` don't work correctly. Specifically, `window.scrollTo(0, 0)` will not scroll all the way to the top, leaving content sitting beneath the nav bar. When `contentInsetAdjustmentBehavior = .never` and the content insets are manually set, `window.scrollTo(0, 0)` scrolls to the correct place. In both cases, the actual contentInset is correct, just depends on the adjustment behavior.


I've attached a sample project that reproduces, and is also on GitHub - https://github.com/zachwaugh/wkwebview-bugs/tree/master/ScrollToContentInset

[Simon Fraser (smfr)]

Wenson, is this the thing you fixed?

[Wenson Hsieh]

At a glance, this bug seems more related to how we handle contentInsetAdjustmentBehavior when content insets are specified; the bug I fixed was about how content insets were being conflated with obscuring insets.

It's possible that the other content inset bug has an impact here, though.

[Zach Waugh]

I retested this bug using my test project with some different results now. The original bug I described exists in iOS 11.2 and earlier. It appears to have been fixed in iOS 11.3 and 11.4. In iOS 12 beta 1, it is broken again, but in the opposite way of the original bug, it works correctly for `contentInsetAdjustmentBehavior = .automatic` and fails for `contentInsetAdjustmentBehavior = .never`. I updated my sample project and readme on GitHub (https://github.com/zachwaugh/wkwebview-bugs/tree/master/ScrollToContentInset) with this info.