So I'm on 10.14.1, with Intel GPU, and cannot repro.

The failures were only seen on 10.13 with ATI.

I'm not sure why that would be different with VizDisplayCompositor on.

Looking at the failure range on flakiness dashboard[1] we see the failures in the range before reverting VizDisplayCompositor as default. And only on 10.13 ATI, other Mac bots were fine, as were other OSes.

The failure is also a timeout of the test.

Looking at the test seems that the mouse event callback isn't being called.

+ccameron@ and riajiang@ any insights?


[1] https://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType=webkit_layout_tests&tests=no-fake-mousemove.html

Mouse event callback timeout does sound hit-testing related, but I can't think of anything that should be different on mac in terms of VizHitTestDrawQuad. It looks like there's no OOPIF involved in the test. 

Maybe the delay to send hit-test data from Viz to browser with OOP-D? Is there a timing difference with OOP-D between different platforms? Although that doesn't really explain why this specific test is flaky. 

This test is under "fast", would marking it slow in https://cs.chromium.org/chromium/src/third_party/blink/web_tests/SlowTests help testing (if I understand what fast tests mean correctly)?

Ah, I hadn't known of that expectations file.

Marking this as slow, to see if we are just timing out, sounds like a great idea. Especially since no other bot was showing issues.

We can then turn OOP-D back on and monitor. I'll put together the patch

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

commit 4ea7f970e03dd551f4b2b95df43f6cd0babf53b0
Author: jonross <jonross@chromium.org>
Date: Wed Dec 12 01:40:36 2018

Mark no-fake-mousemove.html as Slow

When running with VizDisplayCompositor virtual/user-activation-v2/fast/events/no-fake-mousemove.html
was flaking with timeouts. However it was only flaking on one particular bot
WebKit Mac10.13 (retina).

We suspect that the extra process is leading to increased delay in this test.

Marking this test as slow will allow us to confirm that.

TEST=virtual/user-activation-v2/fast/events/no-fake-mousemove.html

Bug:  912364 
Change-Id: Ic04f50efa612782fdf66ecc4cb2ea260defb04a1
Reviewed-on: https://chromium-review.googlesource.com/c/1372470
Reviewed-by: Ria Jiang <riajiang@chromium.org>
Commit-Queue: Jonathan Ross <jonross@chromium.org>
Cr-Commit-Position: refs/heads/master@{#615758}
[modify] https://crrev.com/4ea7f970e03dd551f4b2b95df43f6cd0babf53b0/third_party/blink/web_tests/SlowTests

Per #7, removing Sheriff label.

This was still timing out after being marked slow when OOP-D was enabled by default again. It seems like the mouse event callback is just never being called?

Do you have links to those flakes?

I don't see any on the flakiness dashboard.

Ah, it was virtual/mouseevent_fractional/fast/events/no-fake-mousemove.html that was failing instead. False alarm! I reverted mac OOP-D pretty quickly due to  crbug.com/914981  but no flake in virtual/user-activation-v2/fast/events/no-fake-mousemove.html is promising.

Seems we were just hitting time outs.

No flakes in recent history since updating expectations