Questions about WebXR experience and ARCore

[guptaaditya]

I have a web application that uses model-viewer. The default mode is WebXR with a fallback to scene viewer and quicklook.
Q1. Can I assume every phone that supports scene viewer also supports webxr?
Q2. If user denies permissions for webxr accidentially can I somehow prompt user again in their next session for permission? If not can I guide user on how to enable permission but would like to do that conditionally after knowing that the permissions have been denied.
Q3. In case of NOT SUPPORTED ERROR (explained in 1st issue below), can I before hand know whether this device supports WEB XR? Because this happens when ModelViewer (MV) attempts to start WebXR session but has to fallback to scene viewer? How can I catch this exception? I have tried all try catch in my react app (Around the method that calls activateAR, life cycle hooks and entire application wrapped in try catch, but I do not get this, and when I looked in model viewer code the reason is it just logs the error and doesn't throw that error).
Because of this, I will have to add exception handling for this console error before it gets logged to sentry/error tracking service.
Q4. How often the google ARcore supported devices list is updated? If any new phone model launches in market will we already have that in the list on the website if its certified for ARcore support?
Q5. Is there a way to show in app message, "Your phone doesn't support AR"? How can I implement that in JS?

We have seen various issues:-

1. Samsung Galaxy S22 Ultra: Though ARCore says webxr is supported, it asks for permissions and I also see that webxr joystick sort of icon in addressbar, but it always launches scene viewer. Even when launching scene viewer, after clicking once on launch AR, user has to either click the back button or click on launchAR again after which AR works. It also logs an error "NOT SUPPORTED ERROR". Is there a solution for this? This has been seen only on Samsung S22 ultra.
2. Oneplus Nord 2: After placing the model on floor, sometimes the model just runs to a farther place and gets smaller itself while the arscale is fixed. I tested with 2 different models. One of the model runs away after placement. Another model stayed there, was little flickering and moving here and there but much better than previous one. Sometimes while placing the model, the model gets teleported to some other place in the scene not visible immediately. User to move phone around, up and down, back to search for the model and then its visible.
3. Some Realme devices and other low spec devices prompt for webxr permission on clicking launchAR, but nothing happens. When I search for google play services for AR on these devices, I see a message on playstore on the lines of "AR is not supported on these devices/Not compatible device".

Obviously device specific handling cannot be done, but is there anything that I can do to fix these issues?

Also Despite the fact, that WebXR is default mode, one-plus phones are mostly launching scene viewer and not WebXR.

One can experience what I have live atm at the following link.
https://admin.thridify.com/products/preview/6672abda866aa20fd52bae08/liveonthridify.store

[guptaaditya]

Thank you so much for reading and answering my questions above.

[elalish]

Well, I had thought the answer to Q1 was yes, but based on your experiences, I'm concerned something is broken. I'm not really the expert on WebXR/ARCore, so I'll find someone else to look into the rest of this. Stay tuned.

[guptaaditya]

Thank you for looking into this.

[alcooper91]

Can you confirm what version of chrome you have tested this on? (from chrome://version). Do the errors also repro on Chrome Canary?

We've seen some issues with Samsung and the renderer we've used in the past and have patched that a bit. For that phone sepcifically, can you clarify what the "Webxr joystick" icon you see in the address bar is? Perhaps a screenshot. Do the logs show anything else? You can try also to set chrome://flags#webxr-shared-buffers to "Disabled" and see if that helps anything that would be a huge help as well.

The OnePlus Nord 2 issue sounds like an AR tracking issue

For the Realme, if they do not have ARCore, they should fail the WebXR request before prompting for the permission. Can you confirm what the developer console/logs say and/or confirm the behavior on: https://immersive-web.github.io/webxr-samples/immersive-ar-session.html ?

Overall, it is my understanding that ModelViewer should be handling the graceful fallback to SceneViewer if the WebXR session fails. There are numerous reasons that the sessions could be failing. If you enable chrome://flags#webxr-internals and then relaunch and navigate to chrome://webxr-internals after you've attempted to enter some of these sessions, both the "Runtime Info" and "Session Requests" tabs should be helpful in telling us what is going on.

Q1. I'm not sure of the requirements for SceneViewer. For WebXR, we will need the phone to have ARCore support.
Q2. Unfortunately, we don't expose to the page why the session failed. This answer is in logs, but for privacy reasons we only surface that the session request failed
Q3. Similar to Q2, this is also by design. isSessionSupported is a lot less granular than requestSession and there are many reasons that requestSession may fail (incompatible features, user denied permission, ARCore not available, etc.) I'd expect ModelViewer to do the heavy lifting of falling back during failure for you.
Q4. I'm not sure about this, I believe elalish was going to look into finding someone else who can help answer this.
Q5. You can check navigator.xr.isSessionSupported('immersive-ar'), but this is only a heuristic check. False certainly means false, but True really only means probably (for various reasons, see Q3 for a bit more details).

[elalish]

Q1: SceneViewer also requires ARCore support, which is why usually they both work or neither. But there are some edge cases.
Q5: I believe you can query the visibility state of our AR button - you might need to make a custom slotted button to query it.

Q3: Generally we look at this as internal logic. What exactly are you trying to achieve?

[guptaaditya]

Q3. With understanding that in some phones scene viewer works but WebXR doesn't, I wanted to catch the error NOT_SUPPORTED_ERROR. I see in sentry logs and from model viewer code, that it logs the error but doesn't throw and then falls back to scene viewer. This results into our app reporting an error, which shouldn't be the case. Since you mentioned If scene viewer works, WebXR should work. But thats not always the case. I can confirm this for Samsung S22 ultra. It is one of the flagship model from Samsung, but WebXR doesn't work. Even though I plan to test my app (like the link above) with over 150 different phone models, but regardless would like to handle this error being generated when webxr fails and modelviewer starts.

Further if I could already know whether webXR will work or not, I would default to scene viewer even before user clicks LaunchAR button.

[alcooper91]

Were you able to try it out with the flag I recommended/have the other information on the S22? We've had intermittent issues with Samsung phones due to driver issues and that will help me figure out what's going on. If you can test the S22 on https://immersive-web.github.io/webxr-samples/immersive-ar-session.html as well that would help.