Bug 192564 – Regression (iOS 12): Keyboard dismissal leaves WKWebView viewport-fit=cover content offscreen

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit API

[Darryl Pogue]

Also filed as rdar://44655885

When an input that would require webview centering is clicked, the viewport is repositioned to center that input, as iOS has traditionally done. However, when dismissing the keyboard, the viewport is not re-positioned properly back to its original position.

A test project is available on GitHub: https://github.com/dpogue/WKScrollTest/tree/ios12-keyboard
Run the test project on a device or simulator. Tap the text input field to open the keyboard. Tap the Done button on the keyboard to dismiss it.


Expected Results:
The keyboard overlay closes and the web view is positioned as before: filling the screen.

Actual Results:
The keyboard overlay closes, but the web view does not return to its original position, leaving a space at the bottom of the screen. If rubberband bounce scrolling is disabled, it is not possible to return the web view to its intended position.


I strongly suspect this was introduced as a side effect of https://bugs.webkit.org/show_bug.cgi?id=187743 / https://trac.webkit.org/changeset/233905/webkit


This is impacting several popular frameworks that embed WKWebView:

- https://github.com/apache/cordova-ios/issues/417
- https://github.com/react-native-community/react-native-webview/issues/193
- https://github.com/ionic-team/capacitor/issues/814


Some additional comments from others:

 - when the viewport is in it's "stuck" position it seems as if any web elements still respond to interaction in their proper place. They are visually off the screen, but logically in the correct spot. This is similar to https://bugs.webkit.org/show_bug.cgi?id=158325

- webView.setNeedsLayout() on keyboard dismissal works as a workaround. UI is updated correctly but instantly, not smoothly like in Safari.


It sounds like the issue is essentially that the visible content area is not getting updated when the keyboard closes and the keyboard inset is removed.

[Darryl Pogue]

Did a bit of investigating here.

On dismissing the keyboard, in WKWebView's _contentBoundsExtendedForRubberbandingWithScale we're getting a verticalRubberbandAmountInContentCoordinates of 260, which leads to the content being partly offscreen.

This seems to be due to [_scrollView contentOffset] not being adjusted for the keyboard dismissal at the time that we're reading it, because it is indicating (0, 260)

[David Gölzhäuser]

Is there an update to this issue?

[Ryosuke Niwa]

I was hoping that my fix for https://trac.webkit.org/r240027 would fix this one as well but it didn't so it's back to our queue of the root cause analysis.

[David Gölzhäuser]

This issue only occurs in combination with iOS >= 12 and XCode >=10. Apple requires developers to build Apps with iOS 12.1 and Xcode 10.1 on March 2019.

Am I right, after this issue has been fixed Apple needs to pull the latest WebKit and implement it into iOS WKWebView, or is there some kind of automatic update process?

[Ryosuke Niwa]

(In reply to David Gölzhäuser from comment #4)
> This issue only occurs in combination with iOS >= 12 and XCode >=10. Apple
> requires developers to build Apps with iOS 12.1 and Xcode 10.1 on March 2019.

Hm... that's strange. Xcode version itself shouldn't affect things. Are you also changing the target SDK when you do that? If so, could you tell us in which target SDK you're seeing the issue in iOS 12?

There are certain features and behaviors we enable only when an app is linked against newer SDKs. So if this problem only occurs with newer SDKs, then I suspect one of those features / behaviors are the cause of it.

> Am I right, after this issue has been fixed Apple needs to pull the latest
> WebKit and implement it into iOS WKWebView, or is there some kind of
> automatic update process?

It depends. At some point, Apple make a branch of WebKit for a given release. If the fix has been landed by the time we made a branch, then the fix is likely to stay in the branch unless it caused a regression, etc... If the fix wasn't made by the time a given branch was created, then we'd have to manually merge it into the branch to be included in the release which uses that branch. There is a number of internal processes Apple uses to determine which change is merged into any given branch/release.

[Darryl Pogue]

(In reply to Ryosuke Niwa from comment #5)
> (In reply to David Gölzhäuser from comment #4)
> > This issue only occurs in combination with iOS >= 12 and XCode >=10. Apple
> > requires developers to build Apps with iOS 12.1 and Xcode 10.1 on March 2019.
> 
> Hm... that's strange. Xcode version itself shouldn't affect things. Are you
> also changing the target SDK when you do that? If so, could you tell us in
> which target SDK you're seeing the issue in iOS 12?
> 
> There are certain features and behaviors we enable only when an app is
> linked against newer SDKs. So if this problem only occurs with newer SDKs,
> then I suspect one of those features / behaviors are the cause of it.

This bug only happens when building against the iOS 12 SDKs.

This matches the comments in the https://trac.webkit.org/changeset/233905/webkit

> UIScrollView's _systemContentInset no longer includes keyboard insets
in apps linked on iOS 12+ when contentInsetAdjustmentBehavior is None.

> FirstWhereUIScrollViewDoesNotApplyKeyboardInsetsUnconditionally = DYLD_IOS_VERSION_12_0,

[David Gölzhäuser]

Any updates on this?

[Darryl Pogue]

This is still an issue in iOS 13 beta 8 :(

[Darryl Pogue]

Created attachment 378115 [details]
Patch

[Ryosuke Niwa]

Comment on attachment 378115 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=378115&action=review

Thanks for the patch but we need a API test or a layout test.

> Source/WebKit/ChangeLog:7
> +

We need a description as to how the bug was caused and how it's fixed.

[Darryl Pogue]

Created attachment 378134 [details]
Patch

[Ryosuke Niwa]

Great. Thanks for the patch!

[WebKit Commit Bot]

Comment on attachment 378134 [details]
Patch

Clearing flags on attachment: 378134

Committed r249585: <https://trac.webkit.org/changeset/249585>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.