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

commit 67f9887c36cd46aa4b3d481f2ff1bbffcfbcb8c1
Author: Makoto Shimazu <shimazu@chromium.org>
Date: Tue Jan 30 05:15:57 2018

Mark VRDisplay_rAF_fires_with_window_rAF.html as flaky

TBR=klausw@chromium.org

NOTRY=true

Bug:  807152 
Change-Id: Ie6894445c01f5ec0cfc83b2a955a5b9b56979bd3
Reviewed-on: https://chromium-review.googlesource.com/892586
Reviewed-by: Makoto Shimazu <shimazu@chromium.org>
Commit-Queue: Makoto Shimazu <shimazu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#532766}
[modify] https://crrev.com/67f9887c36cd46aa4b3d481f2ff1bbffcfbcb8c1/third_party/WebKit/LayoutTests/TestExpectations

Could you please redirect?

Not sure why this would be flaky, should see if we can fix, but it's not urgent.

Somebody working more closely with webVR/XR able to pick this up?

+Anna as well.

I have a couple other issues I'm looking at first, but I could potentially look at this next week.  I don't think this needs to be fixed for M68, since its been around since January.

Took a brief look - for the failures I looked at, it doesn't appear we were flaky from getting callbacks out of order - just flaky because we were a millisecond off on reported time.

My guess is some math rounding error.

for future reference - https://chromium.googlesource.com/chromium/src/+/91c1b85524d974f3b9ca143f4da5695b5448f7a8 changed the timing around the same time this was marked as flaky.

Removing Blink>WebVR component and assigning to Blink>WebXR 

Removing Blink>WebVR component and assigning to Blink>WebXR