This sounds familiar to something I was hitting when trying to keep a video element full-screened through the DON flow.

There was some discussion about maybe having a callback right before DON initiated the suspension (which would allow us to save state about what is playing/full-screened etc), but it required work on the daydream side.

I don't know if anything ever came of that.  I search but couldn't find any bugs referencing it (this would have been back in early Dec I think).

On the other hand, for video specifically I think the PRD said that pausing video for the transition (and forcing the user to restart) was actually the desired experience (since we don't know how long it takes a user to put on their headset).

Oh, just reread the description and it sounds like this is about media in a WebVR experience which wouldn't be able to be restarted once WebVR starts (because no user gesture).

The potential solution of getting a callback before DON sounds like it might still work though if Daydream can provide it.

Found the Daydream side bug (thanks bshe@ for cc'ing us on it) that would allow keeping the DON flow in the Chrome activity stack (and therefore potentially resolve the issues) at b/32181531.

mlamouri is working on an autoplay proposal that fixes this, but I'm also wondering, why does entering into VR require a user gesture?

I don't think it's 'Entering VR' that requires a user gesture.  It's actually 'WebVR present' that requires the gesture.

This is (paraphrasing my understanding which may be incorrect) a user browsing in VR doesn't navigate to a new site and suddenly have their entire view taken over by a rogue ad which knows how to start a WebVR presentation.  (There are probably other considerations as well).

bajones IIRC the user gesture is now provided as part of WebXR input; removing from autoplay policy triage list

Removing Blink>WebVR component and assigning to Blink>WebXR