iOS 12 initial scroll positions and scroll indicator insets

[domchristie]

These issues can be demonstrated using the turbolinks-ios demo app running the latest master version.

iOS 11.1 [GIF] works as expected

iOS 12.1 [GIF] scroll indicator is offset (by the height of the navigation bar) and the scroll position is not reset after loading a new page; it seemingly maintains the scroll position of the previous page:

I have looked into this a little, and my guess is that the scrollIndicatorInsets are relative to the content insets (or safe area?), and so are unnecessarily offset again. However, I have not been able to determine why the behaviour differs between iOS 11 and 12. adjustedContentInset and contentInsetAdjustmentBehavior were both introduced recently, but they were both added in iOS 11, and there doesn't seem to be any documentation that indicates a a change between 11 and 12. I'm not sure which behaviour is correct, so perhaps this is an iOS bug which was either fixed, or introduced in iOS 12?

---

Whilst looking into this, I came across this talk from WWDC 2018 about scroll views, which includes the following:

most of the time, if not all the time, you're really going to want to leave [contentInsetAdjustmentBehavior] at [.automatic,] its default value.
…
our last behavior: .never. Now with this one, as you expect, that means the scroll view is never going to adjust its content inset.
However, that has some side effects. For one, that means that the scroll view will end up propagating safe area insets on all of its edges just like a regular view. And as we talked about before, that might end up giving you some behavior you don't really want. For example, if you recall your layout margins are relative to the safe area, which means your layout margins might end up increasing or changing as a result of this. This is also going to disable some very helpful automatic behaviors that scroll view provides like automatic scroll indicator insets. And so if you do a search online and you see a favorite question and answer website suggesting that you set your scroll view's content inset adjustment behavior to .never, consider instead using additional safe area insets to increase the safe area insets. … Or you could consider just modifying the content inset directly

Tyler Fox: https://developer.apple.com/videos/play/wwdc2018/235/?time=1359

As well as Tyler's tweet and so I'm wondering if this is something that turbolinks-ios could adhere to? This wouldn't fix the initial scroll position issue, but I'm thinking it might help with scroll indicator issues in future versions.

[domchristie]

I'm wondering if [the .automatic contentInsetAdjustmentBehavior] is something that turbolinks-ios could adhere to?

I have just seen #116 (comment) so I suppose this is ultimately the aim.

---

FWIW, setting navigationBar.isTranslucent = false seems to fix both issues (and looks nicer than I expected!). Credit to @samoli for this.

[zachwaugh]

There are a number of issues with scrolling and WKWebView in iOS. I've filed numerous bugs, but here's two relevant ones:

• https://bugs.webkit.org/show_bug.cgi?id=182709
• https://bugs.webkit.org/show_bug.cgi?id=182710

Beyond how it looks, it also causes issues with scrolling and placing elements from JavaScript (more details on those with sample projects here - https://github.com/zachwaugh/wkwebview-bugs).

Until those are resolved, your best bet is not placing the web view underneath the navigation bar or tab bar, that's what we ended up doing in Basecamp. Setting navigationBar.isTranslucent = false as the side-effect of not putting the scroll view under the nav bar.