VR Core Production version: 1.4.151195927

Is this a regression between 58 and 59?

It looks like it is, yes. I just checked and it does work with 58.0.3029.83 and it does not work with the above mentioned version and the latest 59.0.3071.33.

Likely related to api changes (but the latest 59 version noted there should have the origin trial disabled).  Are you running with the webvr flag enabled?  If so I think you'll get a different result if you turn it off with versions > 59.0.3071.29

Are we marking sites that haven't upgraded for the deprecated API's as an external dependency?

Yes running with the webvr flag enabled. Still repros with 59.0.3071.39

When I test this I get a black screen initially. After pressing the VR button content presented correctly in stereo. After exiting presenting content is rendered correctly.

On inspection it looks like previously VRFrameData was provided all the time, but a recent change means that it is now all 0 or null until requestPresent is called?

The reason for the black screen is an invalid camera matrix because the FrameData is not valid. After requestPresent it returns to normal.

Has this behaviour changed?

Any thoughts, Klaus, Brandon?

On current Chrome Canary, I also get a blank screen with just the Cardboard icon on initial load. Inspector console shows lots of errors, consistent with the pose not being filled in:

playcanvas-stable.min.js:686 Uncaught TypeError: Failed to execute 'setPosition' on 'AudioListener': The provided float value is non-finite.
    at e.setPosition (playcanvas-stable.min.js:686)
    at c.onUpdate (playcanvas-stable.min.js:960)
    at Function.fire (playcanvas-stable.min.js:23)
    at Function.update (playcanvas-stable.min.js:824)
    at e.update (playcanvas-stable.min.js:806)
    at playcanvas-stable.min.js:821

It looks like it's using this conditional:

a.vr.display.presenting?a.vr.display.requestAnimationFrame(a.tick):window.requestAnimationFrame(a.tick)

Please use vrDisplay.rAF always, even when not presenting. If I manually call vrDisplay.rAF with my own callback, I get screen content displayed as a side effect, but it doesn't track. The pose data only gets refreshed one time per vrDisplay.rAF call, and as soon as I add a manual vrDisplay.rAF loop separately the magic window starts refreshing.

Suggested followup bug: calling getFrameData from outside a vrDisplay.rAF context should either work, or produce a warning that it's the wrong context. Silently returning null poses isn't very helpful.

However, I'll note that null poses are entirely valid, and should be handled appropriately. Right now async pose reading could cause null poses to be received by the page initially, and so should be handled without causing exceptions.

mthiesse@, yes the app should be able to handle null poses, but currently getFrameData still returns "true" when that happens. 

The spec says "Returns true if the the provided VRFrameData object was successfully updated, false otherwise". It's not clear which case should apply for a partial update, but IMHO the pose is the most important part for most applications.

Filed  issue 736023  "WebVR: inconsistent getFrameData while not presenting" and a corresponding spec bug https://github.com/w3c/webvr/issues/246 for followup.

I've updated WebVR lab to call display.requestAnimationFrame all the time, not just when presenting.

This fixes this issue in Chrome Beta.