Probably the best way to do this is to only create the object that owns these on requestSession(). We could either delay ARCoreDevice (and similar) creation or have a private implementation class backing it.

I'm changing the summary to address the general problem.

Removing Blink>WebVR component and assigning to Blink>WebXR 

Removing Blink>WebVR component and assigning to Blink>WebXR 

@billorr says 1 day for a simple fix and ~5d for refactoring that would make it more general across other devices. When fixing this bug, please file a new bug for a larger fix if you only do the simple fix.

@billorr : what is the impact of not fixing this bug? do you think this is required/MUST (P1) or should fix (P2)?

ARCoreDevice has been refactored to clean up some of this, but we still create the mailbox_bridge_ and the context provider in ARCoreDevice's constructor.  When that is ready.  When that completes, we create arcore_gl_thread_ and start it.  We do delay initializing arcore until the ar dfm is installed.

GvrDevice has been changed to initialize when either VRDisplayInfo is needed for webvr (through EnsureInitialized()) or when a session is requested.

Desktop devices also need to be updated to delay initialization.


The 1-day "simple fix" is to just avoid calling mailbox_bridge_->CreateUnboundContextProvider() until requestSession, along with appropriate checking that we are in a valid state throughout.

With the larger refactor, browser-side requestSession will now do 1. call into provider to check that it can support the session. 2. call into the provider to ensure everything is up to date. 3. request permissions.  4. call into the device to actually request the session, which will start the runtimes and initialize the device if needed.  Note that step 4 requires the simple 1-day fix, but also applied to other devices.

I would consider 846521 to be blocking this, and it is effectively the 1-day fix specific for AR.

I filed issue 907591 to track the desired overall outcome. It's not clear to me what specific part of that this issue tracks or whether it is now a duplicate. Feel free to use it for whatever makes sense to move us towards the desired outcome in issue 907591.