Open domchristie opened 5 years ago
I'm wondering if [the
.automatic
contentInsetAdjustmentBehavior
] is something that turbolinks-ios could adhere to?
I have just seen https://github.com/turbolinks/turbolinks-ios/pull/116#issue-150615593 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.
There are a number of issues with scrolling and WKWebView in iOS. I've filed numerous bugs, but here's two relevant ones:
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.
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
andcontentInsetAdjustmentBehavior
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:
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.