WebView Content scrolls under navigation bar when going back

[michiels]

I have a problem with my Turbolinks iOS app that my webview content scrolls under the navigation bar when my app goes back to that page. The app consists of two screens. The first where you choose a year, and then that links to a page where some content is displayed. When you go back, the year selector screen suddenly scrolls under the navigation bar.

Here are three screenshots to illustrate the problem:

Initial position:

After tapping a year (new VisitableViewController on navstack):

Then tapping back via the navigation bar:

This seems similar to https://github.com/turbolinks/turbolinks-ios/issues/46. Setting the following does actually help, but is not the behavior I want.

    override func viewWillAppear(animated: Bool) {
        super.viewWillAppear(animated)
        self.edgesForExtendedLayout = .None
    }

Since this seem like a pretty obvious think that happens (also in Basecamp app for example), what am I doing wrong or is this a bug that has been recently introduced? It seems that Turbolinks scrolls the webview to the wrong position after going back.

[samoli]

I'm also having this problem. I think it's because of the change in 65657ae9fd03850a2fdcceee153cf63970fea132

When activateWebView is called after pressing back, it looks like the insets top & bottom are frequently 0. Switching back to the old behavior, or removing the line updateContentInsets() from activateWebView seems to fix it.

cc @dginsburg

[zachwaugh]

Are you still experiencing this? We're not having this issue in our app.

[henrik]

We're seeing a possibly related issue that we were able to reproduce in the demo app (see below). Simulated iPhone 8 Plus, iOS 11.

What we're seeing is this:

• If we tap the first link in the demo app and then back again, everything looks right.
• But if we scroll the first page (even a tiny bit) before we tap the first link, then the next page will be scrolled wrong. And if we then go back, the first page jumps to the wrong position as well.

Here's a gif:

To reproduce, we made the pages longer so we could scroll them. Here's that diff:

diff --git a/TurbolinksDemo/server/lib/turbolinks_demo/views/index.erb b/TurbolinksDemo/server/lib/turbolinks_demo/views/index.erb
index 99f4e7d..bc7e14e 100644
--- a/TurbolinksDemo/server/lib/turbolinks_demo/views/index.erb
+++ b/TurbolinksDemo/server/lib/turbolinks_demo/views/index.erb
@@ -9,3 +9,7 @@
   <li><a href="https://github.com/turbolinks/turbolinks" target="_blank">Follow an external link</a> to open it in Safari.</li>
   <li><a href="#" data-behavior="post-message">Post a message from JavaScript</a> to see how it can be handled natively.</li>
 </ul>
+
+<p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</p>
+<p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</p>
+<p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</p>
diff --git a/TurbolinksDemo/server/lib/turbolinks_demo/views/one.erb b/TurbolinksDemo/server/lib/turbolinks_demo/views/one.erb
index aa346ff..f3406ff 100644
--- a/TurbolinksDemo/server/lib/turbolinks_demo/views/one.erb
+++ b/TurbolinksDemo/server/lib/turbolinks_demo/views/one.erb
@@ -7,3 +7,7 @@
 <p><strong>or</strong></p>

 <p><a href="/two" data-turbolinks-action="replace">Here's a link to another page</a> that does a <em>replace</em> instead of an <em>advance</em>
+
+<p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</p>
+<p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</p>
+<p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</p>

[michiels]

Hi @zachwaugh

Yes. I'm still experiencing this. Just upgraded to 2.0.0 Pod and re-tried with the same app as my original issue.

[calleluks]

I have investigated this further and found that:

• On iOS 10, @samoli's fix (as quoted below) indeed seems to solve @michiels' original issue.

  Switching back to the old behavior, or removing the line updateContentInsets() from activateWebView seems to fix it.

• On iOS 11, the trick of using a hidden scroll view with automatically adjusted insets no longer seems to work. The inset of the hidden scroll view is never adjusted. Therefor, @samoli's fix doesn't seem to have any effect.

  Despite the hidden scroll view trick not working, content isn't always displayed underneath the navigation bar. Looking at the view hierarchy in the Xcode view debugger, it seems like the WKWebView automatically adjusts its contentOffset setting the y property to -64. This works as long as the web view isn't manually scrolled before clicking a link. When it is manually scrolled before clicking a link contentOffset.y is set to 0 causing the issues described by @henrik. Maybe this has something to do with moving the web view from one view controller to another?

• On iOS 10, after applying @samoli's fix, I found another issue where quickly tapping a link, tapping back, tapping another link, and tapping back again caused the original page to scroll to the top. I have no idea why this is happening. Due to the iOS 11 issue above, I couldn't see if this also happens on iOS 11.

I wonder if letting the WKWebView be the first subview of the view controller's content view rather than wrapping it in a VisitableView would let us rely on the automatic adjustment of scroll view insets?

@zachwaugh, how did you solve this for the iOS 11 version of the Basecamp app?

[zachwaugh]

Thanks for the investigation @calleerlandsson! A while back we switched to opaque nav bars in Basecamp due to some design changes, which is probably why it hasn't affected us.

There are new APIs in iOS 11 for handling insets, such has UIScrollView.contentInsetAdjustmentBehavior ( https://developer.apple.com/documentation/uikit/uiscrollview/2902261-contentinsetadjustmentbehavior), as well as the other safe area inset APIs. I'm planning on refactoring how we handle all that in Turbolinks and see if we can't do a better job there, but I don't have immediate time to do that.

[zachwaugh]

I did some investigation today and believe I fixed the main issues mentioned in this PR - https://github.com/turbolinks/turbolinks-ios/pull/116. Can anyone try that and see if they still any issues?

[michiels]

@zachwaugh Awesome. That was some rapid " but I don't have immediate time to do that." ;-) I'll see how I can get the PR branch in my Podfile (never did it before) and test it.

[michiels]

@zachwaugh / all

I can confirm this works with Pod built with #116 branch. In the following GIF you do not see the scroll position "jumping" when pressing back:

[henrik]

Tried merging this and the swift-4 branch, and then used that in our Podfile, but it seems our issues remain :/ We'll dig further later in the week and post an update.

[zachwaugh]

@henrik hmm, you should be able to just use the fix-scrolling branch as it's based off the swift-4 branch. Let me know what you find out, but that branch fixed it in the cases I could find.

[henrik]

Hey @zachwaugh. We've dug further and it turns out the issue in the GIF above was fixed (thank you so much!), but another issue remains, that we haven't yet mentioned.

We have implemented a "tap the current tab bar item again to scroll to top" feature, but it doesn't account for the navigation bar. Here's another GIF of us first tapping the tab bar item again (scrolls wrong), then the clock (scrolls correctly).

This is the code we use to scroll:

session.webView.scrollView.setContentOffset(CGPoint(x: 0, y: 0), animated: true)

Any ideas? We'll keep digging.

[zachwaugh]

You'll need to take into account the content inset of the scroll view. That's true for scroll views in general (not just related to Turbolinks), we use an extension on UIScrollView for doing a similar thing in our app:

extension UIScrollView {
    func scrollToTop() {
        setContentOffset(CGPoint(x: 0, y: -contentInset.top), animated: true)
    }
}

[zachwaugh]

And thanks for confirming the fix! Merged this and swift-4 branch into master and tagged a new v3.0.0 release.