Keyboard dismissal leaves viewport shifted in iOS 12 & 13

Originator:darryl
Number:rdar://44655885 Date Originated:20-Sep-2018 14:31
Status:Closed Resolved:25-Mar-2020 12:00
Product:iOS + SDK Product Version:12.0
Classification:UI/Usability Reproducible:Always
 
Summary:
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.

Steps to Reproduce:
Run the attached test case 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.

Version:
12.0

Notes:
The test project is also available on GitHub: https://github.com/dpogue/WKScrollTest/tree/ios12-keyboard

Comments

Fixed in iOS 13.4

My fix for this was accepted in WebKit and released in iOS 13.4

By darryl at April 3, 2020, 7:36 p.m. (reply...)

iOS 13 beta 1

This issue is still present in the iOS 13 beta 1 🙃

By darryl at June 3, 2019, 10:45 p.m. (reply...)

Any progress on this? None of the workaround really seem feasible for me, and more and more users are on iPhone X sized/viewport-fit=cover devices.

By redshocker4 at Jan. 20, 2019, 9:41 p.m. (reply...)

WebKit bug report

In an attempt to bump up the priority on this (since it sounds like it's as simple as a missing recalculation of visible content), I've also filed https://bugs.webkit.org/show_bug.cgi?id=192564

By darryl at Dec. 10, 2018, 8:01 p.m. (reply...)

For the record, I strongly suspect this was introduced as a side effect in https://github.com/WebKit/webkit/commit/0ff63c48b7456d6b72b0e751a600d9e3d14dbdeb

By darryl at Nov. 2, 2018, 4:04 a.m. (reply...)

For cases where you don't have control over the app's native code, but only the web code, I've found that it's possible to force the layout to be recalculated with something like window.scrollTo(x, y). You can call that after a delay on the blur event, assuming you know where you need to scroll to. For my application, there's no scrolling involved, so I can simply call window.scrollTo(0, 0).

By ravron at Oct. 29, 2018, 6:18 p.m. (reply...)

scrollView.contentOffset reset

Appears to be related to the webview's scrollView.contentOffset not being properly reset in this scenario.

See also: a workaround in this cordova-plugin-ionic-webview PR - https://github.com/ionic-team/cordova-plugin-ionic-webview/pull/201/files

By brent.dearth at Oct. 29, 2018, 5:56 p.m. (reply...)

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

By my.name.is.amirk at Oct. 19, 2018, 8:57 a.m. (reply...)

Brutal Bug

It appears that this is related to viewport-fit=cover meta being used in a WKWebView in iOS 12. This is causing us quite a few headaches as the principle method for handling iPhoneX notch styling in a webapp involve using this meta. Disabling the viewport-fit=cover or reverting to UIWebView seem to resolve this particular bug, but neither are viable resolutions.

By brent.dearth at Sept. 21, 2018, 1:25 a.m. (reply...)

To add to this report, when the viewport is in it's "stuck" position it seems as if any web elements still respond to interaction in their proper place. For instance, if you have an input fixed to the bottom of the screen, when the keyboard closes, the viewport remains shifted up and the fixed element disappears. But if you tap where the input should be, it takes focus again and renders back into the view properly when the keyboard opens. Super brutal for pages trying to emulate a messaging app since the fixed textbox functionality is critical.

By smathson at Oct. 17, 2018, 10:29 p.m. (reply...)

Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!