It looks like error page issue, michaeldo@ would you take a look? 

It looks like this may be an issue with the way that CRWWebControllerContainerView adds the |_nativeController| above the web view and interacts with the iPhone X "notch".

CRWWebControllerContainerView sets the frame of |_nativeController| directly instead of using constraints to match it to it's own size. It's |layoutSubviews| does get called on rotation of the screen, but that doesn't take into account the notch or safe area.

eugenebut@ and kkhorimoto@: Do you guys have any thoughts on using constraints here to add the view instead? Or of another way to avoid the notch collision?

NativeController will be removed, so moving it to use NSLayoutConstraints could be wasteful. Can we account for safeAreaInsets when setting view frame?

Well there are a couple things going on here:

1) The WKWebView's frame extends beyond the safe area layout guide, but WKWebView has internal logic that renders content in the viewport resulting from the safe area layout guide.
2) The error page is also displayed using a WKWebView with the same frame.  After following the repro steps, the bug will be fixed by scrolling the content.  None of the frames or constraints are getting updated here; it's just handled internally by WKWebView.

It's unclear why WKWebView handles the post-rotation viewport correctly for normal web pages and not the error page (I checked on wikipedia, cnn).  One way to fix this might be to debug the html used to generate the error page.  

However, I don't think anyone on the team is really super familiar with the code that generates the error pages.  Another solution would be to update CRWWebControllerContainerView to size its subviews according to the safe area layout guide.  This would in effect be manually implementing the viewport resizing that WKWebView already attempts to handle internally when rendering.

I tried to account for safeAreaInsets when setting frame, and it fixes the issue, but it looks very bad because the webpage background color (grey) stops reaching the edge and there is a square white border around the page. So we can't use that solution.

I also was unable to "fix" the page by scrolling after the repo steps. It looks like the insets are broken on the right until reload or another orientation change back to portrait.

I previously had looked into the html source and I think it's ok since it is always the same and renders correctly without the UI rotation.

I am still looking into alternative solutions.

Could this be WKWebView bug? Maybe we can create a test WKWebView app to demonstrate the bug?

I am able to fix this by adding the native content view with constraints. PTAL at crrev.com/c/942026.

However, I will wait to land that CL until after branch to ensure it gets well tested.

It turns out that adding those constraints did introduce breakages on the NTP, so I will reset the Status of this bug to Assigned.