Bug 177023

Summary: [Chrome] WKWebView scrolls content into the unsafe area when focusing form fields on iPhone X Simulator
Product: WebKit Reporter: Eugene But <eugenebut>
Component: WebKit2Assignee: Nobody <webkit-unassigned>
Status: RESOLVED CONFIGURATION CHANGED    
Severity: Normal CC: thorton, webkit-bug-importer, wenson_hsieh
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: iPhone / iPad   
OS: iOS 11   
Attachments:
Description Flags
Test App
none
Chrome in iPhone X simulator
none
Safari in iPhone X simulator
none
Video of another test case with iPhone X layout
none
Test app which throws logs into console none

Description Eugene But 2017-09-15 13:17:02 PDT
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).
Comment 1 Eugene But 2017-09-15 13:17:13 PDT
rdar://34466367
Comment 2 Eugene But 2017-09-15 13:18:30 PDT
Please comment on this bug if have any tips how to workaround the problem.
Comment 3 Tim Horton 2017-09-16 19:33:20 PDT
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?
Comment 4 Eugene But 2017-09-18 08:59:26 PDT
Created attachment 321095 [details]
Chrome in iPhone X simulator
Comment 5 Eugene But 2017-09-18 08:59:48 PDT
Created attachment 321096 [details]
Safari in iPhone X simulator
Comment 6 Eugene But 2017-09-18 08:59:57 PDT
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!
Comment 7 Tim Horton 2017-09-18 09:33:47 PDT
Ooooooh, your test app is meant to be run in landscape, got it. Now I see what you're saying.
Comment 8 Tim Horton 2017-09-18 09:35:13 PDT
If you scroll the view, it corrects itself, it's just the initial zoom-to-focus that is offset.
Comment 9 Eugene But 2017-09-18 09:40:38 PDT
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.
Comment 10 Tim Horton 2017-09-18 09:45:58 PDT
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?
Comment 11 Eugene But 2017-09-18 10:07:10 PDT
Created attachment 321102 [details]
Video of another test case with iPhone X layout
Comment 12 Eugene But 2017-09-18 10:07:14 PDT
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?
Comment 13 Tim Horton 2017-09-18 10:10:21 PDT
(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.
Comment 14 Eugene But 2017-09-19 10:45:16 PDT
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!
Comment 15 Eugene But 2017-09-19 10:45:56 PDT
Created attachment 321211 [details]
Test app which throws logs into console
Comment 16 Tim Horton 2017-09-19 10:49:12 PDT
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.
Comment 17 Eugene But 2017-09-19 11:32:54 PDT
Filed a separate bug per comment #13:
https://bugs.webkit.org/show_bug.cgi?id=177175
Comment 18 Eugene But 2017-09-20 14:00:29 PDT
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.
Comment 19 Tim Horton 2017-09-20 14:38:59 PDT
(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.
Comment 20 Eugene But 2017-09-20 14:43:17 PDT
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.
Comment 21 Tim Horton 2018-01-08 20:14:55 PST
This seems to be totally fixed in trunk. Probably by additional adoption of adjustedContentInset.