Thanks for the report!  I'll look into this.  Just to clarify, looking at both videos, I don't see any difference in the final layout of the page.  Are you referring to the fact that in the |expected_video.mov|, the grey "Chrome" bar on the bottom gets momentarily positioned a bit higher than needed (by about its own height), with some white space below it, but then gets laid out correctly on the bottom in the next frame or so?

If this is the problem, I don't think I'm seeing it on the latest Mac Canary, though it's possible that this is because my Macbook is too fast to see it.  Would you mind re-checking there to see if it's been fixed?

So it is definitely doing layout with a viewport size that is a little bit too small, and then getting layout again immediately afterward with the correct size.

bokan@: Do you have any thoughts on what the smaller size might correspond to?

For context, the bisected change made it so that the main frame starts out as a remote frame after a cross-process navigation, and then gets swapped in to a local frame when the navigation completes. What I'm guessing is happening here is that something is wrong about the viewport size when we have a remote main frame -- we do try to anticipate this and cache correct size information on VisualViewport in case the main frame later gets swapped in, but maybe we are missing something?

After the main frame becomes local, it looks like the viewport size becomes correct, but not before at least one full layout and paint have already been done.

There's no URL bar on desktop so I don't know what might be causing that. Is it non-0 but smaller than the real viewport? That'd be surprising. We do have some complexity around resizing frames after the first layout but that only kicks in if the minimum page scale is < 1 which it never should be on desktop. 

You could add some logging and stacktraces to LocalFrameView::SetFrameRect (on desktop, the layout size will be set from the frame rect in LocalFrameView::FrameRectsChanged inside SetFrameRect) to see where the unexpected size is coming from.

I wonder if this has to do with the bookmark bar being there and then going away. The repro steps as given only reproduce on Mac, and maybe the difference is because of the cocoa view.

Interestingly, I see something similar on Linux when I run a trunk build and and do this immediately after launch, where there is a butter bar for "Google API keys are missing." When the butter bar is present on the NTP, and I click the Apps bookmark, then I see the same effect on the Apps page of it drawing too small and then immediately resizing.

I haven't been able to test this on an older build to see if the 'Linux with butter bar' behavior regressed at the same time as the Mac behavior.

kenrb@, I think you have more context on this than I do and a few good leads - would you mind taking this over?  This doesn't seem to be very high priority, since the final layout and behavior of chrome://apps is correct, but it would be nice to know if there's indeed an incorrect layout size that we're temporarily using during a remote-to-local transition.  I'm afraid I won't have time to look into it in the short term as I need to focus on a few other things.