issue 672654  is related.

cc bshe, who's written a doc that probably covers this.

Yes, that's definitely related. It would be great to have a link to that doc.

And //chrome/browser/ui/webui/vr_shell [C++] 
//chrome/browser/resources/vr_shell/ [Js and HTML] contains VR implementation, too.
Since I worked on  issue 652080  before, maybe I could help on this.

That's great additional information, thanks! bshe@chromium.org, do you have a link to the doc mentioned in c#1?

Re: helping out, that sounds great as well! It sounds like the starting point is looking at bshe@'s doc and then understanding and coordinating on the work that there is to do and who would do what when.

Documenting some understanding I gained here:

- Web starts a VR presentation flow via VRDisplay::RequestPresent(). That call ultimately ends up in VrShellDelegate.java in //chrome (the dependency is earlier injected via the //device-level GvrDelegateProvider::SetInstance()).
- Seems only to result in functionality (a) on Android and (b) if Daydream or Cardboard are being used.
- Significant coupling to the browser, from browsing the //chrome-level Java code.

It seems like to decouple the VR impl from the browser, substantial parts of the //chrome-level code would need to move into the Device Service. However, the cutpoints are not clear.

Biao's doc can be found at go/webvr-windows-refactor

Can non-googlers access that document?

The above doc is deprecated. A new doc has created by Bill. The doc is probably not at a stage that can be shared publicly. But +ddorwin to answer your question.

Design and documentation is still a WIP. One of the goals is clearer interfaces and separations. We'll keep this in mind.

Removing DeviceService label as VR is not going to end up in the Device Service but rather in a distinct service.

having issue in your browser take help from us opera support number
https://babasupport.org/browser/opera-customer-service/162