Is this P1? And if so, is it realistically going to happen for 61?

At the very least we should investigate to see if we have bugs here before M61, and see if we should escalate.

bajones and klausw: ping

Looking at the code, I don't think we are doing anything "wrong" here - just maybe a little bit inefficient.

It is true that we don't immediately reset pending_vrdisplay_raf_ during cancelAnimationFrame, however, when the vsync message arrives we will set pending_vrdisplay_raf_ to false, and with the current behavior we have unregistered the callback so we won't tell javascript about the vsync.  After 1 vsync we'll stop triggering VSyncs.

Given the async nature of the callbacks, I think it is simpler and easier to get correct waiting for the roundtrip from mojo/doc vsyncs before setting pending_vrdisplay_raf_ to false.  In particular, the site could already have multiple requests for animation frames, or may add some after the cancel but before the outstanding vsync arrives.

That all said, I think this could be cleaned up a bit to make it more clearly correct and efficient.  pending_vrdisplay_raf_ sort-of means pending_outstanding_vsync_ as well currently despite the name.

I recommend dropping priority and moving out to 62.

No need for a milestone on this one, this is technical debt work.

Removing Blink>WebVR component and assigning to Blink>WebXR