Detected 26 new flakes for test/step "MouseLatencyBrowserTest.MouseDownAndUpRecordedWithoutSwap". To see the actual flakes, please visit https://chromium-try-flakes.appspot.com/all_flake_occurrences?key=ahVzfmNocm9taXVtLXRyeS1mbGFrZXNyRAsSBUZsYWtlIjlNb3VzZUxhdGVuY3lCcm93c2VyVGVzdC5Nb3VzZURvd25BbmRVcFJlY29yZGVkV2l0aG91dFN3YXAM. This message was posted automatically by the chromium-try-flakes app.

Assigning based on Issue 800303. 

Detected 19 new flakes for test/step "MouseLatencyBrowserTest.MouseDownAndUpRecordedWithoutSwap". To see the actual flakes, please visit https://chromium-try-flakes.appspot.com/all_flake_occurrences?key=ahVzfmNocm9taXVtLXRyeS1mbGFrZXNyRAsSBUZsYWtlIjlNb3VzZUxhdGVuY3lCcm93c2VyVGVzdC5Nb3VzZURvd25BbmRVcFJlY29yZGVkV2l0aG91dFN3YXAM. This message was posted automatically by the chromium-try-flakes app.

I uploaded a revert at https://chromium-review.googlesource.com/c/chromium/src/+/937041. Will close once this is landed.

This has been disabled on Windows in January:

https://chromium-review.googlesource.com/c/chromium/src/+/856578

I would suggest that this test is just flaky and not the fault of my CL.

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

commit 300e022bcfdd800dcebd99902adc8b77190b432f
Author: Takuto Ikuta <tikuta@chromium.org>
Date: Mon Feb 26 04:24:56 2018

Disable flaky MouseDownAndUpRecordedWithoutSwap test

Bug: 815363
Change-Id: I2e46eac205c902914332c1f11423350273b77ba0
Reviewed-on: https://chromium-review.googlesource.com/936724
Reviewed-by: Timothy Loh <timloh@chromium.org>
Reviewed-by: Fady Samuel <fsamuel@chromium.org>
Commit-Queue: Takuto Ikuta <tikuta@chromium.org>
Cr-Commit-Position: refs/heads/master@{#539069}
[modify] https://crrev.com/300e022bcfdd800dcebd99902adc8b77190b432f/content/browser/renderer_host/input/mouse_latency_browsertest.cc

fsamuel@, assigning this to you since you wanted to disable the test instead of revert. In these situations (note that the patch caused over more than half of linux_chromium_rel_ng tryjobs to fail or be flaky) I prefer to revert, but this also could've been avoided entirely if you had a look at the tryjob failures instead of just hitting CQ+2 a second time.

This test in general has been flaking across OS. Additionally it doesn't even work with VizDisplayCompositor (see issue 791557)

The test itself relies on two different methods for receiving the ui::LatencyInfo which it wants to verify:
  -  CompositorFrameMetadata during frame submission (not available in Viz)
  -  OnMouseEventAck

Where it arrives depends on if there's a frame that the gpu will swap.

It's racy by nature, and I wouldn't be surprised if there was some underlying bug that makes it miss both.

There are plans to re-work LatencyInfo, so getting this test working again may be best to block on that.

I'm definitely not the right person to be assigned this bug. Passing to tdresser@ for triage.

Over to Navid to triage.