gambard@ as soon as you scroll the problem fixes itself, right?  Or is the grey patch permanently there?  In my testing I think it goes away as soon as you interact with anything in the web page.

Adding kkhorimoto@ and eugenebut@ It looks like when we change size classes and hide the tab strip, we aren't refreshing something in fullscreen?  Assuming gambard@ confirms, I think the problem corrects itself, but I'm not sure what needs to be kicked so the web page's grey background isn't shown.  Any ideas?

Yes it goes away after scrolling.

It seems like there's some sort of internal state that needs to be updated when the screensize/traitcollection changes, and we hide the tab strip, to correct fullscreen, but I wasn't able to figure out the magic incantation.

I tried various hacky approaches from BVC::traitCollectionDidChange just to see if I could get it working (kicking -_toolbarUIUpdater's updateState, kicking crw_web_view_scroll_view_proxy's 
 _observers's webViewScrollViewDidScroll, etc.  Nothing seemed to clean it up.

Punting to kkhorimoto@ for better fullscreen knowledge.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c2a89e2c51ea4bb1b8de6aa40acc5a65d0f6c8f9

commit c2a89e2c51ea4bb1b8de6aa40acc5a65d0f6c8f9
Author: Gauthier Ambard <gambard@chromium.org>
Date: Tue Aug 28 09:54:29 2018

[iOS] Fix toolbar updater of rotation

This CL fixes the toolbar height calculated by the
LegacyToolbarUIUpdater on rotation. Previously the updater wasn't
notified on the rotation, leading to a wrong toolbar height after
rotation.

Bug:  849206 ,  876275 
Cq-Include-Trybots: luci.chromium.try:ios-simulator-full-configs;master.tryserver.chromium.mac:ios-simulator-cronet
Change-Id: I33c0f0ed4c535f2f6fbf9e089e0f38b00f6692e0
Reviewed-on: https://chromium-review.googlesource.com/1188571
Commit-Queue: Gauthier Ambard <gambard@chromium.org>
Reviewed-by: Kurt Horimoto <kkhorimoto@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586636}
[modify] https://crrev.com/c2a89e2c51ea4bb1b8de6aa40acc5a65d0f6c8f9/ios/chrome/browser/ui/browser_view_controller.mm
[modify] https://crrev.com/c2a89e2c51ea4bb1b8de6aa40acc5a65d0f6c8f9/ios/chrome/browser/ui/toolbar/legacy_toolbar_ui_updater.h
[modify] https://crrev.com/c2a89e2c51ea4bb1b8de6aa40acc5a65d0f6c8f9/ios/chrome/browser/ui/toolbar/legacy_toolbar_ui_updater.mm

I have submitted a patch modifying the rotation, moving from a grey patch to a white patch :)

The white patch is here because the frame is now correct, but the scrolling offset the WKWebView scrollView is wrong, because of our adjustments for fullscreen.

I am working on fixing this, so I am taking this bug.

Thanks Gauthier!

I won't be able to solve this for M70, pushing it to M71.

kkhorimoto@ would you be interested in taking a stab at this?

The way to fix it is probably linked to the fact that we are changing the content offset of the scroll view when modifying the frame.
We don't want to increase the complexity of the Fullscreen implementation in Web so I am moving it to chrome to be able to do it.

I don't reproduce it with the BCVC fullscreen flag enabled, so I am marking this as fix.