Known issue with the changes made to the WebVR implementation for M62. The displayActivate event is now a user gesture, where controller clicks are not, so vr.with.in will require some code changes on their end.

 Issue 761600  has been merged into this issue.

There are several issues here:
When using a cardboard headset in VR, there is an unhandled exception when using the cardboard "click", which is exposed as a 0-dof 1-button gamepad.  THREE.VRController.supported doesn't have a member for this gamepad.

Second, when you enter VR with a click event on the button, video does appear to play eventually, but we get this error message: https://developers.google.com/web/updates/2017/06/play-request-was-interrupted

Finally, this issue (and error message in the console) indicate that play() can only be invoked from within a user gesture.  However, it appears to sometimes work with the gamepad that doesn't generate a user gesture.

There is a fourth issue that the environment is black and no UI is shown if playback is started before the user enters VR, either via the button or inserting the phone into the headset. If the user clicks the controller button and looking around (it seems to be 90 degrees off from where the user was looking), the user can find the playback UI and resume the video by clicking the PAUSE button.

The original issue (and the last one in #6) repros in Beta 61.0.3163.72 as well, so this is not a regression in M62 and not due to the removal of the "Cardboard-compatible" click event ( issue 716571 ).

Even when I click on the PAUSE button to try to start playback, nothing happens. This appears to indicate that the click event was not being used.

New in M62, inserting the phone in the headset generates a user gesture ( issue 756564 ), so play() should work now. It's not clear why it doesn't, but it may have something to do with the page "navigating"[1] after the gesture. Since playback works when using the Enter VR button, the page may be doing something to work around this only in the Enter VR case.

[1] While it appears to be the same page, the URL changes from the original page (https://vr.with.in) to the player page (e.g., https://vr.with.in/watch/the-possible-speed-machine).

Issue 745886 has been merged into this issue.

There is a user action for displayActivate.  vr.with.in could use this to start playback, wait for the play promise to resolve then immediately pause playback, then when the user actually wants to play something play again.

Issue 747004 has been merged into this issue.

This works now. 62.0.3202.29 Daydream Pixel XL

Reopening the issue, it is still reproducible in 63.0.3231.0
Important note: Issue is repro if to enter VR by inserting device into headset. Issue is not reproducible if to enter VR by tapping "Enter VR" on the vr.with.in webpage.

The Within Team is tracking this and will have updates on our end shortly. Most likely the week after OC4. Thanks!

Sorry for the delay on this. We're internally QAing a number of changes that should alleviate all the issues raised in this thread. We're going to have it out shortly and will update when it's live.

In the meantime I'd like to address the latter half of Comment 8 concerning the URL changing. On vr.with.in we are using the HTML5 History API to change the URL as you poke around. The Oculus Browser Team raised an issue that changing state kicks you out of VR in GearVR. So what we're doing is: while you'r in VR we keep a localized variable of what the URL "should" be. Then when you leave VR we change the History to reflect the new URL. Because of this ddorwin@ is correct in assuming that https://vr.with.in/watch/the-possible-speed-machine is the same code. We have special routes setup so that every route except for static assets (like images, models, and JavaScript files) points to our index page.

Hope this clarifies the URL changing front. We believe the issue ddorwin@ was having is unrelated to the History, because it's working (in our staging environment) now that we have correctly adopted vrdisplayactivate to play media.

Update - this still repros on Chrome 64.0.3274.0

We've pushed significant updates to vr.with.in which include listening for the vrdisplayactivate event and listening for more controllers. We still don't support the cardboard controller however. Happy New Year to all!

This appears to be working in Chrome build 66.0.3355.0.  Verified on Pixel 2 with Android 8.1.0

Updating the milestone to when the external site was fixed so it's more relevant.