Does the test use ARC++ or any exo apps? This bug might have already been fixed by kylechar@?

Oh boy, this is confusing. I'm assuming this is cc::mojom::FrameSinkManagerClient not the newly added cc::FrameSinkManagerClient? The second one has an identical method but is used for something totally different than the first. The second one shouldn't be involved in any deserialization though.

Anyways, this means that someone is submitting a malformed CompositorFrame which produced an invalid SurfaceInfo. The StructTraits for SurfaceInfo calls SurfaceInfo::IsValid(), which checks three things:

bool is_valid() const {
  return id_.is_valid() && device_scale_factor_ != 0 &&
      !size_in_pixels_.IsEmpty();
}

It could be any of those. Do we know what the test is checking for? It looks like the test does invoke ARC, so it might be that I fixed it already when I fixed device_scale_factor with exo, but it could also be an invalid SurfaceId or an empty CompositorFrameMetadata::output_rect.

Reading through the test invokes arc, so I think this should be fixed at ToT with this https://codereview.chromium.org/2843723003/.
 
https://chromium.googlesource.com/chromiumos/third_party/autotest/+/HEAD/client/site_tests/cheets_CTSHelper/cheets_CTSHelper.py

Can we mark this as FIXED then?

I'll mark this as FIXED. Please reopen if this is still an issue.

Yep, I think it should be fixed but haven't had a chance to test on a device that supports exo.