As a part of addressing Surface Synchronization bugs I am looking at confirming the state of invariants violations within the browser. A WIP change for this adds a new check in RenderWidgetHostImpl: https://chromium-review.googlesource.com/c/chromium/src/+/1379972

The goal is to not have RenderWidgetHostImpl::SynchronizeVisualProperties send a synchronization message to the render if the size has changed, but the LocalSurfaceId has not.

When running in multiprocess Mash I see this new check being hit in LoginUtilsTest.MashLogin:
./out/cros/browser_tests --gtest_filter=LoginUtilsTest.MashLogin --enable-features=Mash --disable-features=SingleProcessMash --disable-features=SingleProcessMash

It can also be reproduced after logging in. Or if starting multiprocess mash without the --login-manager

This does not reproduce for normal Chrome OS configs.

What appears to be happening is that the bounds are being changed in an animation, from an initial empty bounds:
  RenderWidgetHostViewAura::InternalSetBounds 0,0 1280x800
  RenderWidgetHostViewAura::InternalSetBounds 0,0 0x0
  RenderWidgetHostViewAura::InternalSetBounds 0,0 1100x657
  RenderWidgetHostViewAura::InternalSetBounds 0,0 1100x657

Which differs from normal confiugarion which only ever sets to 1280x800

I have a temporary work-around, updating WindowPortMus::OnDidChangeBounds to generate a new LocalSurfaceId. This matches the behaviour of WindowPortLocal and prevents the check from being hit.

However I have not looked into the root cause of the difference in behaviour of the bounds