Not working on Chrome 87 in iframe + blob(?)

[monoto]

isSessionSupported('immerisve-vr') always returns false for latest release 0.3.1. SketchFab suggests installing Steam and SteamVR. Why is that necessary with WebXR emulator? Anyone encountered the same issue? The state of XR is really in a mess right now. Keeping WebVR and watching on the sideline still...

[takahirox]

Hi, thanks for the report.

isSessionSupported('immerisve-vr') always returns false for latest release 0.3.1.

I guess you chose a device which doesn't support VR? Would you please choose VR compatible device (e.g. Oculus Quest) in WebXR devtool panel and try again?

[monoto]

I think I found out what the possible cause is. I am testing with a local server with Chrome's "Allow invalid certificates for resources loaded from localhost." flag enabled, which results in an insecure connection... and WebXR requires a secure connection?
So the question is how can I test XR emulator from local server without a certificate?

[takahirox]

Native WebXR API requires secure context to run but currently the WebXR Emulator extension should run even on insecure context. (I may change it in the future.)

I'm not sure if I'm facing the same problem you faced, but I realized that on Chrome 88 the Three.js WebXR examples doesn't run on local dev server while they run on their online servers... (I haven't tested the other WebXR apps yet.)

On both the local dev server and their online servers, the following console error appears when I attempt to enter an immersive mode.

Uncaught (in promise) DOMException: An attempt was made to use an object that is not, or is no longer, usable.

On their online server I enter an immersive mode after the console error while I couldn't on the local dev server... I will investigate the problem but I guess it's a browser side problem?

They seem to run on Firefox without any problems so using Firefox may be an easy workaround so far.

[arpu]

i think this is related to this Problem mrdoob/three.js#20754

[monoto]

I'm not using three.js and I am calling

navigator.xr.isSessionSupported( 'immersive-vr').then( supported => {
if (supported) {}
});

directly without await.

In both 88 and 87, supported returns false for Oculus Quest.

Tested with an online secure server just now, and I got supported=false still.

[monoto]

Upon further investigation, the problem is iframe. It needs special privilege to run VR and XR. This thread can now be closed. My suggestion, the same origin policy should enable VR and XR for an iframe by default.

[takahirox]

isSessionSupported('immersive-vr') returns true here even in iframe. For example, Three.js WebXR VR examples are in iframe and they work.

https://threejs.org/examples/#webxr_vr_ballshooter

Would you share an online page where I can reproduce the problem?

[monoto]

If you look into their iframe's attribute in developer console, it says

<iframe id="viewer" name="viewer" allowfullscreen allowvr onmousewheel src="webxr_vr_ballshooter.html"></iframe>

Looks like it is using WebVR, not WebXR, otherwise it should include this attribute:

allow="xr-spatial-tracking"

[takahirox]

Let me clarify what you reported. isSessionSupported('immersive-vr') always returns false in iframe on Chrome 87 or newer if the extension is installed, correct?

[monoto]

Let me make you a test case. Will update you a link for testing.

[monoto]

Go here: https://www.otakhi.com/petridish?load=15723

Once the page loads, click the play button at bottom right corner.
Follow by clicking on the green square which executes:

var self = this;
navigator.xr.isSessionSupported( 'immersive-vr').then( supported => {
 var msg = 'immersive-vr supported=' + supported;
   self.message.text = msg;
});

The outcome is displayed in the green square.

The HTTP response header of that page contains

Feature-Policy: xr-spatial-tracking 'self';

And the inner iframe has the attributes allowvr="yes".

You can change the script it executes by altering the script in the script popup.
Double-click on the script icon in the green box will open that popup.

[takahirox]

The root issue seems that Web extensions are not loaded in iframe in that example. I guess the extensions can be loaded in static iframe like Three.js examples but they can't be loaded in iframe dynamically added like your example.

Did your example show true before Chrome 87?

[monoto]

It shows true in Firefox. WebVR works with WebVR Emulator in dynamic iframe. Only WebXR having issues. Never tried XR before. Want to see where it is at.

[takahirox]

I confirmed it shows true in Firefox.

I noticed that the content in that example is blob. I guess Chrome stops to load the extension for blob because of security reason?

I thought the current configurations of matches or permissions in manifest.json can be the reason so locally changed them to <all_urls> but the extension still couldn't be loaded.

[monoto]

Perhaps it is a temporary design decision. Once the standard settles, Google will add another feature policy or simply enables it. I will contact Chromium team to figure out.

[monoto]

From https://bugs.chromium.org/ discussion:

This is due to the fact that both the Oculus and SteamVR runtimes don't have the type of sandboxing support that we need in order to enable them by default. 
The runtimes that do support sandboxing, Windows Mixed Reality and OpenXR, will work out-of-the-box. 
It's worth noting that at least Oculus has indicated publicly that they are developing an OpenXR runtime, and it's our hope that when released it will have the appropriate sandboxing support needed to "just work". 
I do not know what Valve's plans are for OpenXR support.

Until that support is released, however, the OpenVR and Oculus runtimes can be enabled with one of the following command line options.

For SteamVR/OpenVR headsets:
--enable-features=openvr --disable-features=XRSandbox --force-webxr-runtime=openvr

For Oculus headsets:
--enable-features=oculus --disable-features=XRSandbox --force-webxr-runtime=oculus

Please note that these command lines do disable the sandboxing of the GPU process, which may incur some security risks. As a result we do not recommend using that mode for daily browsing, and it should be utilized primarily for development and testing purposes.

more info at this link, https://immersiveweb.dev/chrome-support.html

Does this mean anything for WebXR device emulator ?

[monoto]

I suspect the latest Chrome is loading OpenXR runtime directly from manufacturer's DLLs. And it must support sandboxing interfaces in those DLLs. If that's true, they'd bypass any javascript shim code and render any emulator ineffective? Just a thought.

Let me correct myself, WebXR is at the very top layer. The emulator should be able to intersect all WebXR Calls to the hardware. ... except sandboxing. So the question is. Does Chrome allow extension to return TRUE about sandboxing support?

A likely scenario is that Chrome bypasses emulator and query hardware driver to see it supports sandboxing, if not, it doesn't even bother loading the extension. Just a guess.

[monoto]

I did find a working example online. So the culprit is likely the blob url in an iframe. I've posted a bug report to https://bugs.chromium.org/. Let's hear what they say.

Further research seems to indicate that the developers' consensus is that the iFrame's SRC must use "HTTPS" for WebXR to work in Chrome. Firefox is clearly less restrictive in this respect.

[monoto]

After migrating my app to use direct url instead of blob, I can confirm that it is indeed the culprit. This thread can now be closed. Thank you for your time.

[takahirox]

Hi, thanks for the investigation.

I've posted a bug report to https://bugs.chromium.org/.

Could I have the URL to your ticket?

[monoto]

https://bugs.chromium.org/p/chromium/issues/detail?id=1172640

[takahirox]

Thanks!