I'll take a look tomorrow. If this turns out to be spam then maybe we should simply mock out the display compositor in some of these tests?

Additionally, this SurfaceId reporting is currently not very debug friendly. I've filed a couple of bugs to make SurfaceId spew more debug friendly.

I think [mash_]browser_tests are supposed to be the real deal so we shouldn't have mocks in them. It's likely a real bug.

I wonder what process those log messages are coming from? There should only be a SurfaceManager instance being used in service:ui, but there could still be one in service:content_browser?

It's coming from service:ui. This line in surface_manager.cc is what I think it causing it.

https://cs.chromium.org/chromium/src/cc/surfaces/surface_manager.cc?sq=package:chromium&dr&l=324

That check was removed a month or two ago and readded recently. Something tries to add a surface reference before the surface exists but the reference gets dropped. This ends up breaking other lifetime assumptions and surfaces end up garbage collected early?

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

commit 8761c218a237d2bd6ea05547ad5e578de0a9a855
Author: kylechar <kylechar@chromium.org>
Date: Wed Apr 19 21:54:07 2017

Fix SurfaceIds in mus with surface sync off.

WindowPortMus was sending SurfaceIds (a) too early and (b) that weren't
the right SurfaceId causing lots of log spam with mus and surface sync
turned off.

BUG= 711544 

Review-Url: https://codereview.chromium.org/2831763002
Cr-Commit-Position: refs/heads/master@{#465767}

[modify] https://crrev.com/8761c218a237d2bd6ea05547ad5e578de0a9a855/ui/aura/mus/window_port_mus.cc

The check that child SurfaceId exists wasn't actually the problem. SurfaceIds were being propagated early and the surface was being embedded before it existed with surface sync turned off.