This is flaky because the new TracingRenderWidgetHost is partially relying on a signal which is not available in Viz.

RenderWidgetHostImpl::OnGpuSwapBuffersCompletedInternal is only called when a GpuBrowserCompositorOutputSurface is being used.

However in Viz this work is all done in a separate process and GLOutputSurface is in use instead.

+chiniforooshan@ to comment on if this tracing information is being provided to the browser process via other signals.

Can you copy-paste the error output? Also, how can I reproduce the failure? Thanks.

The test times out when running with --enable-viz

./out/Debug/content_browsertests --enable-viz --gtest_filter=MouseLatencyBrowserTest.CoalescedMouseMovesCorrectlyTerminated

jonross@ yes I talked to Sadrul about this model. 

It seems it is untestable in the model for Viz. So viz needs to figure out how this is supposed to work.

Who can own this bug?

I'm not familiar enough with the LatencyInfo event that you are waiting on to know if this is untestable in Viz.

Since you mentioned this is flaky in Viz, does that mean that sometimes it passes via the OnMouseEventAck path?

If so then the LatencyInfo is still being delivered to the browser process. In which case TraceRenderWidgetHost just needs to also listen to an additional signal. Since this is tied to tracing I believe that it does, though chiniforooshan@ would know more on that.

If the LatencyInfo is not available in the browser process at all in Viz, then we can look into building an appropriate test api. If that's the case assign this to me and I'll triage.

It is flaky because it is based on timing whether the latency info object gets terminated in the normal input event ack or the gpu swap.

If there is a pending frame it might get put in the gpu swap. If there isn't then it gets terminated in the input event ack.

The problem is that in viz the LatencyTracker exists in two processes the viz process and the browser process. And this test demonstrates the problems with that.

Thanks for that info about that race!

I just synced up sadrul@ offline about the paths that LatencyInfo takes to the browser. There currently isn't another path if the race you mentioned failed.

However I'm making a new api to send all frame metadata to the browser process. So I'll be able to unblock this test once that done.

I'm taking this bug and marking it blocked on  issue 775103 

Thanks!

MouseLatencyBrowserTest.MouseDownAndUpRecordedWithoutSwap also flakes on Windows:

error: Value of: trace_event_names
Expected: has 4 elements and there exists some permutation of elements such that:
 - element #0 is equal to "InputLatency::MouseDown", and
 - element #1 is equal to "InputLatency::MouseDown", and
 - element #2 is equal to "InputLatency::MouseUp", and
 - element #3 is equal to "InputLatency::MouseUp"
  Actual: { "InputLatency::MouseDown", "InputLatency::MouseUp", "InputLatency::MouseUp" }, which has 3 elements

The test is disabled in non-viz too on Windows and Linux. The test probably should be rewritten.

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

commit cc5553473908c3ba5fb436d9a67612b0e091a31b
Author: Sadrul Habib Chowdhury <sadrul@chromium.org>
Date: Tue Mar 13 19:40:30 2018

viz: Remove one more from content_browsertests filter.

The MouseLatencyBrowserTest.CoalescedMouseMovesCorrectlyTerminated test
is very flaky, and disabled on most platforms. We can remove it from the
filter for viz. When the test is fixed, it should be done in a way so
that it works with viz.

BUG=791557

Change-Id: I2e08fd9f8d14133021a733f01c79d3cca157a2c9
Reviewed-on: https://chromium-review.googlesource.com/961089
Reviewed-by: Jonathan Ross <jonross@chromium.org>
Cr-Commit-Position: refs/heads/master@{#542881}
[modify] https://crrev.com/cc5553473908c3ba5fb436d9a67612b0e091a31b/testing/buildbot/filters/mojo.fyi.viz.content_browsertests.filter
[modify] https://crrev.com/cc5553473908c3ba5fb436d9a67612b0e091a31b/testing/buildbot/filters/viz.content_browsertests.filter

This should no longer block oop-d.

Since this test is not just flaking in viz, and is tied to input I'm assigning to riajiang@ to help triage to an appropriate owner.