1. The whole point of DrawLayers is to make a CompositorFrame to be drawn on the screen. Doing all that just to send a piece of metadata is very expensive.

2. I recognize this is for tests so maybe more reasonble there but it's also very easy for test things to end up getting used for other stuff because it exists.

3. Is there some better channel for this data then?

4. There is already a work around to not skip the frame when touch handle visibility changes for probably similar reasons, for android also. Maybe you could cargo cult onto that. https://cs.chromium.org/chromium/src/cc/trees/layer_tree_host_impl.cc?rcl=4e1f66f1c92879d5ae8b2f75273fc8e73975cdea&l=810

BTW I'm not convinced this is limited to tests. 
 RenderWidgetHostViewAndroid::OnFrameMetadataUpdated is doing a bunch of stuff with overscroll effects and whatnot.

I don't know enough about this area to answer #3.  I'm also not blocked on this, since adding a call to WebLayer::ShowScrollbars from VisualViewport::UpdateScrollOffset avoids the issue, but I wanted to file this to capture my findings.

> 1. The whole point of DrawLayers is to make a CompositorFrame to be drawn on the screen. Doing all that just to send a piece of metadata is very expensive.

This cost really doesn't matter if it's a super occasional scenario in reality.  However, if we universally push frames on metadata change, there is a risk that some metadata property might flap around and cause frames to unnecessarily be pushed at 60fps.  I think that's the only real performance concern here.

> 3. Is there some better channel for this data then?

No, I really don't want to go back to a world where scroll offset information is sent asynchronously from frames themselves.

Maybe we need to be able to SubmitCompositorFrame with metadata only, and cc can decide based on damage then. Cuz computing all the transforms etc to update a scroll offset isn't the best.

I guess ContentViewScrollingTest#testOverScroll has this behavior because the test page is mostly blank, and CC is smart enough to avoid damage when scrolling from white to more white?  That's a real corner case for sure.

It seems this test is indirectly protecting us from scrollbar-disappearing bugs, that might even be useful although the only problem is that the reason might be unclear to developers.  I can't think of any action I particularly think is worth doing to improve the situation, so WontFix I guess.