michaeldo@ could you please take a look at this. 

This doesn't seem to be related to Fullscreen. Unfortunately, it looks like a difference between Safari and WKWebView.

bokan@ The article referenced only applies to Android (although it is confusing that Android Chrome is compared to Safari on iOS). Chrome on iOS uses WKWebView internally  due to App Store restrictions. Please compare results from WKWebView and SafariViewController to see the difference. ("WebView - WKWebView and UIWebView rendering" app on the iOS App Store can be easily used to compare.)

Also, I noticed in the "broken" state you can't zoom in on the page at all. However, in Safari where the page is rendered correctly, you can zoom on the page.

I found this WebKit bug which may be related? https://bugs.webkit.org/show_bug.cgi?id=145614
This user reports seeing the same behavior: http://stackoverflow.com/questions/40637553/different-behaviour-in-wkwebview-and-safari-regarding-css

We recently changed the behavior of how hiding/showing the URL bar resizes the page on Android Chrome. This was done largely to improve interop with Safari iOS, so that's why we're comparing the two. iOS Chrome still works like Chrome Android used to so the difference is a pain for developers trying to make their pages/apps work everywhere.

I've tried the app you suggested to see the difference but it seems that with WKWebView the URL bar doesn't hide at all. I'm assuming that Chrome disables the built in UI toolbars and adds the Omnibox, manually handing the hiding/showing behavior. This means that Chrome should be able to adjust behavior of how the omnibox hides. Granted, this may be difficult/impossible if WKWebView doesn't give us enough hooks into how the content is drawn which I suspect may be the case (you'd have to be able to resize the WKWebView without changing the layout size).

For the zooming issue, perhaps WKWebView doesn't handle pinch zoom gestures itself? Or it's an issue with the app. The bug you linked is to do with Cmd+ zooming on the desktop. The stackoverflow issue looks like a difference in how some CSS is handled so I'm also not sure it's relevant.

WKWebView has no toolbars. Even though that app doesn't hide the toolbar, the issue was still reproducible as far as I could tell. The orange bars are the same height.

I believe the links are relevant as they expose that the "vh" unit is not handled correctly inside WKWebView, but it is handled correctly by Safari on iOS.

Deleted: WKWebView.PNG 72.6 KB

	WKWebView.PNG 72.6 KB View Download

Deleted: SafariViewController.PNG 127 KB

	SafariViewController.PNG 127 KB View Download

The stack overflow issue indicates that the top nav menu just doesn't show up at all. If it was the difference in vh unit size something on the page would just be a different size, not gone altogether.

If there's no bar that scrolls away, Chrome on Android also keeps them the same size (e.g. when in fullscreen mode or when the top controls are locked to "show") so from that perspective WKWebView works the same way. The problem is there's no way to "hook-up" a WKWebView to a URL bar in a way that makes it work like Safari of Android Chrome does. We'd need a new API in WKWebView to make that possible.

I see, so it sounds like this is a known issue with WKWebView and we would need an API to set the top nav bar height to fix this, is that correct?

Quick peek at the WKWebView API doesn't show anything related so I think that's the case, yes. Simply stated, "it's impossible to build a URL bar that behaves exactly like native mobile browsers using WKWebView"

michaeldo@, do you know what the appropriate forum to request such an API with Apple would be? I presume this would be iOS rather than WebKit, right?

Filing a Radar with Apple would be the best first action.

Danyao/Ali - possibly something you might want to look into at some point?  Bling having different web-exposed URL bar behavior from Chrome and Safari (which have now finally aligned - https://github.com/bokand/urlbarsizing) seems pretty bad to me!

#10 - this is apparently not solvable by Chrome or the application, it seems to be a general iOS WebView difference from Safari.

There is no radar for this.
Can you check if this is still an issue?

It's still an issue

https://stackoverflow.com/questions/51157489/is-there-a-safe-way-to-use-max-height-css-media-query