stephentodd@ Thanks for the issue.

As this is marked as Feature, changing the status to Untriaged and requesting someone from Blink>WebVR team to look into the issue and help in further triaging.

Thanks..

David, could you assess the feasibility of this, then set its state accordingly?

This was previously considered and abandoned for  issue 667520 .

http://chromedriver.chromium.org/ can be used to drive Chrome and provide user activation. (There is also https://web-platform-tests.org/writing-tests/testdriver.html for Web Platform Tests.)

Does your use case involve a single page or multiple/navigation? If the latter, how is the navigation happening without access to a keyboard or mouse (not mentioned in the description)?

Thank you for that response, sorry so long to get back, on holiday.

 Issue 667520  and the associated discussion https://codereview.chromium.org/2543723002 were focused on testing.  Our use case involves production runtime, for example in an exhibition, where the complete startup sequence (start Windows, user login, start chrome, start our WebVR application, enter VR, run main exhibition part of application) is automated when the invigilator powers the machine on.  All subsequent interaction is via the Vive headset and controllers.

The weak link is the roundabout way we need to enter VR. The new flag would be used in much the same way that --start-fullscreen is used: except --start-fullscreen does start in fullscreen without code interaction, whereas the flag would still require the requestPresent call, just not from user interaction.

chromedriver could almost certainly do what is needed, but seems like overkill and would be an extra complication in exhibition setup on new machines.

The application does not involve multiple pages; if it did navigation would probably be via setting location.href.

mustaq: Are there general mechanisms for bypassing user activation requirements in such cases? Could starting Chrome with a URL be an indication of user intent to interact? (This might not make sense for payments, for example.)

What about unmuted autoplay in such scenarios?

One can call Chrome with "--autoplay-policy=no-user-gesture-required" to disable the autoplay policy. This is needed for tests and also allows switching policies. In the long run, I would expect this to simply become a way to disable autoplay for tests.

Please make sure that by passing user activation here applies _only_ to entering VR mode.

Also note the risk of abuse: this feature could be a target for abuse, like popups.  We have an option to disable popup blocker, not sure what fraction of users use the option.

Removing Blink>WebVR component and assigning to Blink>WebXR 

Removing Blink>WebVR component and assigning to Blink>WebXR