Bug 177023 – [Chrome] WKWebView scrolls content into the unsafe area when focusing form fields on iPhone X Simulator

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: WebKit2

[Eugene But]

Created attachment 320955 [details]
Test App

WKWebView resizes itself causing web content to be rendered under camera and sensor shelf.

Steps to Reproduce:
1.) Build and run attached test app
2.) Tap on Google Search text field

Expected Results:
WebView should not resize

Actual Results:
WebView unexpectedly resizes so Google Search text field appears under camera and sensor shelf.

Version/Build:
iPhone X simulator from Xcode 9.0 (9A235)

UIWebView does not have this problem (changing USE_UI_WEB_VIEW to 1 fixes the bug).

[Eugene But]

rdar://34466367

[Eugene But]

Please comment on this bug if have any tips how to workaround the problem.

[Tim Horton]

What's happening here is that the page is scrolling when you focus the input field -- it's expected that content can sit in the unsafe area in the direction that you can scroll in -- see the same thing happening with a scrollable page in Safari, for example. It's also expected (I think) that we scroll to center input fields. And the page is vertically scrollable because it is designed to be (it always lays out to slightly taller than the viewport).

The same thing happens with UIWebView... it scrolls a bit more, so you don't get exactly the same overlap, but if you scroll back up a bit you still get content under the status bar/in the unsafe area.

Can you specify which part of this you don't expect or disagree with?

[Eugene But]

Created attachment 321095 [details]
Chrome in iPhone X simulator

[Eugene But]

Created attachment 321096 [details]
Safari in iPhone X simulator

[Eugene But]

Thank you for the explanation. "Chrome iPhone X.png" is a screenshot of Google Chrome displaying Google search page. On that screenshot search suggestions are cut in the same way as they were cut in attached test WKWebView app. We'd like to find a reasonable way to prevent the page from expanding into status bar area. 

Safari ("Safari iPhone X.png" screenshot) does not allow WKWebView to expand and Google Search Page looks much better there. So I was wandering what changes could we make to a test app to have behavior similar to Safari.

Thank you!

[Tim Horton]

Ooooooh, your test app is meant to be run in landscape, got it. Now I see what you're saying.

[Tim Horton]

If you scroll the view, it corrects itself, it's just the initial zoom-to-focus that is offset.

[Eugene But]

Apologize for the confusion with the orientation. Do you know if there is a way to prevent WKWebView from expanding to status bar area in landscape? "Chrome iPhone X.png" is only one example where the page is obscured by camera and sensor shelf. There are other cases where the web page looks pretty bad in Chrome and test WKWebView app, but looks good in Safari.

[Tim Horton]

You certainly have the *option* to lay the WKWebView out inside the safe area, instead of depending on WebKit's support for cascading safe area insets. The normal UIKit documentation (https://developer.apple.com/documentation/uikit/uiview/positioning_content_relative_to_the_safe_area) would be more help with that than I can be.

> There are other cases where the web page looks pretty bad in Chrome and test WKWebView app, but looks good in Safari.

Do these other cases also involve focusing input fields? If not, can you file bugs about them?

[Eugene But]

Created attachment 321102 [details]
Video of another test case with iPhone X layout

[Eugene But]

Thank you for the link!

>>> Do these other cases also involve focusing input fields? If not, can you file bugs about them?
There is a case when focusing input fields is not necessary (see immersiveBack.mov video). Should I file a separate bug for that?

[Tim Horton]

(In reply to Eugene But from comment #12)
> Thank you for the link!
> 
> >>> Do these other cases also involve focusing input fields? If not, can you file bugs about them?
> There is a case when focusing input fields is not necessary (see
> immersiveBack.mov video). Should I file a separate bug for that?

Yes.

[Eugene But]

Regarding this bug. If you run new attached ConstraintsWKWebView.zip project in iPhone X (orientation does not matter) and tap on Google Search field then Xcode throws bunch of "Unable to simultaneously satisfy constraints." logs into console. 

Which makes me think that the workaround for this bug will not only require activating correct NSLayoutConstraints, but also deactivating incorrect NSLayoutConstraints, which WKWebView has by default.

Hopefully this will be useful for you. Thanks!

[Eugene But]

Created attachment 321211 [details]
Test app which throws logs into console

[Tim Horton]

We don't make any autolayout constraints in WebKit.

The solution to the original bug that you reported here is to make the form-zooming code take the unsafe area into account. It should be fairly straightforward, just needs to be done.

[Eugene But]

Filed a separate bug per comment #13:
https://bugs.webkit.org/show_bug.cgi?id=177175

[Eugene But]

Tim, could you please clarify what do you mean by "make the form-zooming code". Set specific  Layout Constraints to prevent WKWebView from expanding into Safe Area? Or have the code which manually updates WKWebView's frame every time when incorrect resize happens? 

Thanks.

[Tim Horton]

(In reply to Eugene But from comment #18)
> Tim, could you please clarify what do you mean by "make the form-zooming
> code". Set specific  Layout Constraints to prevent WKWebView from expanding
> into Safe Area? Or have the code which manually updates WKWebView's frame
> every time when incorrect resize happens? 
> 
> Thanks.

I mean... fix the bug in WebKit. I'm not sure there's a way for clients to work around this without just completely insetting the WKWebView inside the safe area. Unfortunate, I know.

[Eugene But]

The bug is not reproducible in Safari. So I was wandering if you have any hints on how to fix the problem in the attached Test App.

[Tim Horton]

This seems to be totally fixed in trunk. Probably by additional adoption of adjustedContentInset.