Is this happening with Safari running on iPhoneX simulator? If so, let's file a b/ report as well.

Looks like a duplicate of  crbug.com/764935 .

This is the general problem with having WebContents area too wide on iPhone X. pkl@, I believe there will be many more bugs filed for the same problem, so funneling this through you, so you can find right people to fix UI.

 Issue 764935  has been merged into this issue.

Lindsay, could you please upload the video for Safari.

Works fine in Safari. Broken in test WKWebView app.

WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=177023
rdar://34466367

Sorry I was ooto Fri. 

fyi Luke

Stepan, Jean-François, could you please help with this bug. The problem happens because WKWebView has layout constraints which allow web view expansion out of safeAreaLayoutGuide rect. This is probably a bug because WKWebView throws a bunch of "Unable to simultaneously satisfy constraints" errors in the console even in the test app (attached). 

I was told that you understand Layout Constraints and I thought that you can help. Would you mind building attached ConstraintsWKWebView.zip app and trying to fix constraints for WKWebView? I think that the right fix would be adding these:
[webView.leftAnchor constraintEqualToAnchor:webView.safeAreaLayoutGuide.leftAnchor].active = YES;
[webView.rightAnchor constraintEqualToAnchor:webView.safeAreaLayoutGuide.rightAnchor].active = YES;

and removing constraints which are in conflict.

lukestebbing@, would it be possible to implement a suggestion from Apple engineer?:
https://bugs.webkit.org/show_bug.cgi?id=177023#c16

eguenebut@, do you mean the suggestion to scroll the view?

I'll take a look once I get a Simulator build from lindsayw@.

lukestebbing@ I think "make the form-zooming code" is something related to a web page. If the suggestion does not make sense to you then perhaps "form-zooming" is something iOS UI specific that I don't know.

eugenebut@ I'm not sure what it refers to, although my first guess would be iOS's default zooming of forms in web pages (for instance, visit https://daringfireball.net/ on an iPhone and tap the searchbox at the bottom of the page).

Since the Google searchbox font-size is set to 16px, iOS shouldn't autozoom. As far as I know, the search page itself doesn't implement any form zooming.

Fails in Landscape. But may affect position of typeable area when rotating phone back to portrait.

Oh, ok. Maybe "make the form-zooming code" means something else...

jif@, stkhapugin@, could you please take a look if something can be done with Layout Constraints per comment #8.

Apple engineers explained "make the form-zooming code". It's a change that should be made in WebKit. Correct Layout Constrains in Chrome is probably the only viable fix for the bug. 

I can confirm that I could repro this in the Simulator and that manually scrolling fixed it, but programmatically scrolling via scrollTo() didn't fix it. It sounds plausible that the only viable fix is WebKit-side.

However, the same search results page on Safari (also in iPhone X simulator) works properly.

lukestebbing@ - Does SRP have some code that is running in Safari that isn't sent to Chrome?

Note that the problem exists on google.com home page as well. Steps:
- Visit google.com
- Tap inside the search box
- See attached screenshots of Chrome vs. Safari.

Deleted: iphonex-chrome.png 129 KB

	iphonex-chrome.png 129 KB View Download

Deleted: iphonex-safari.png 149 KB

	iphonex-safari.png 149 KB View Download

As far as I know, the SRP has no such code for Safari. +janakj in case he has any ideas.

Have you tried a minimal repro with an <input type=text> at the top of a webpage and no JS?

I think this is just WebKit's zoom-to-form code, but I have no idea why it doesn't affect Safari.

This bug is also reproducible in stock WKWebView app. I think Safari does not allow web view expansion to unsafe area (where camera and sensor shelf is located).

I suppose it's not impossible we have some CSS directives for Safari, but as Luke implies, I'd be skeptical of that causing this specific behavior.

I like Eugene's approach here, you may also be able to test with some generic HTML as well to help narrow this.

Any update on this?

 Issue 779633  has been merged into this issue.

Hi, lukestebbing@ and janakj@. iPhone X is in the hands of real users now. Google.com is still showing some janky movements of the search box with Chrome that isn't showing up in Safari. See comment 17 above. The behavior on App Store version of Chrome (M62) is similar (but worse).

I've taken a couple of screen captures:
Safari - https://drive.google.com/open?id=1PO44AoppJsMz7cKHFaQ3RkdxKUiTB_qD
Chrome - https://drive.google.com/open?id=1dggHFk-dyXmRY1CrLemQhcwPFUV-A8eR

eugenebut@: Were you able to do a minimal HTML repro in the stock WKWebKit app?

pkl@: Judging from https://bugs.webkit.org/show_bug.cgi?id=177023#c19, this isn't caused by CSS/JS on Google.com and it's not possible for CSS/JS on Google.com to work around it.

lukestebbing@ I did not prepare test html file. I filed radar with www.google.com as an example.

lindsayw@ srikanthg@ does spoofing Safari's user agent in Chrome make a difference?

Chrome with Safari UA looks just like good old Chrome:
https://drive.google.com/open?id=1sKsSnvzDS48cRnWYRX_pA2zGE2lLWzGD

This is very likely not Search CSS related, then.

I will also note that the searchbox/page doesn't appear to be full-width as it is on, e.g. Chrome on iPhone 7+.

As Luke said this seems more fundamental to WKWebView and insets. We should come up with a plan for that webkit bug as it sounds like solutions here are dependent on that.

This hasn't really been resolved yet, but M-63 has already been submitted to App Store review. Moving milestone.

re: comment 25, @eugene can you please list the radar tracker id here?

comment #6 has a reference to radar and WebKit bugzilla bug.

Thank you!

Fixed in WebKit trunk (Per Apple's engineer comment): https://bugs.webkit.org/show_bug.cgi?id=177023#c21

Should this be marked as fixed then?

This is not fixed in Chrome yet, only in WebKit trunk.

I say mark as ExternalDependency. We probably won't see this resolved until iOS12 is shipped in October 2018. 

I do think there is a workaround for this bug by setting correct NSLayoutConstraints. Lindsay, is this bug reproducible with Firefox?

Yes the same steps do look the same on Firefox:
Screenshot: https://drive.google.com/file/d/0By4O1f2IQqQ_VWVTLWJtTVd4d00/view

Thanks Lindsay! It is still a mystery to me why Safari does not have this bug. Perhaps private API usage :(

Apple claims this is fixed in 11.3.  Can we retest?

Anyone has a iPhone X with 11.3 beta?

Looking into the bug now. I updated mine yesterday.

Looks good to me.
Verified on iPhoneX, iOS11.3, M64 stable and M66 canary.

Google web search box is displayed correctly after rotating. Did few other tests around the search box and everything looks good.

eugenebut@ I think we can close rdar://34466367 and this bug, but I want to confirm with you since you wrote the sample.

Thanks, Justin! Closed radar.