See also related issue 716087 which is specifically intended for detectable unrecoverable issues such as failing to schedule a new frame due to missing rAF.

Michael, I recall you saying something about the difficulties we might have determining if this is truly a slow app or slowness that's "on purpose". Could you please comment on the feasibility of fixing this issue?

Thinking about this some more, this might be one of those Hard Problems™.

Some confounders for poor performance detection:
1. Splash screens. Brandon proposed doing splash screens by passing a static layer like an image, or a div as the VRLayer. I don't know whether or not this is spec'd yet. For now though, apps will just reproject a single rendered frame, or periodically update a loading indicator, and may do so at any point for, say, level loading, etc.
2. Performance optimizations. What if apps want to do the same type of optimization we want to do for Chrome itself, where we only redraw when the scene has changed? They might appear to render at a low/jittery frame rate, but actually be perfectly fine. We could be outright preventing that if we added UI for slow apps.

If we actually wanted to implement this, we'd need some way of detecting missed frames, where we know, or are at least highly confident that, the app was *trying* to render a frame and was late, repeatedly.

Assigning to Brandon to figure out what we can actually do here within the spec and with the restrictions imposed by desktop where the splashscreen approach may not work or would require Chrome to do things in the background to re-submit frame and avoid timeouts.

Removing Blink>WebVR component and assigning to Blink>WebXR