Catch an error when activateAR() fails

[AntonioMartinezC]

The thing is I am strugeling with permission detection and that I can not figure out how to check with js if some "xr" permission is set according to all documentation i could find there is no such thing?

Buuuuuut it would be super nice if there would be a way to do something like try{activateAR()} catch(err) {console.log(err)} is there any way to do that before i mess with the lib? ^^

[AntonioMartinezC]

The case I need this for is for one when a user denied the permission not knowing what it was for or just by accident and then the button just does nothing all of the sudden and the other is that older devices detect as "yes we can do web xr and yes we can do immersive ar sessions" and then they cant. And working with blob the model just turns out as completely black altho ar modes are only set to webXR and quicklook (happening on android and ios, although i believe the ios version is grey and not black which would align with my experience with gltf/usdz)

[elalish]

My understanding of browser security/privacy is they don't want you to access info like that, but feel free to experiment. This is why we say it's so important to have the 3D view before the AR button, as this helps convince the user to accept that permission.

Can you start a separate issue about the blob problems? I'm not really following, so we'll need screenshots showing right and wrong and a repro link.

[AntonioMartinezC]

Yes I agree with the whole preparing users for the request of permissions completely. In my case there is a whole modal thing explaining the ar mode + controlls + how to interact with what is displayed. However if somewhere in the process the request is denied it kinda breaks. Model-viewers normal behaviour is that it hides its AR-Button as soon as it failed to display AR (with the reason of missing permissions/ lacking capabilities of the device) in my case I have buttons that can be placed anywhere on the page and on click will use the startAR() function from a specified model-viewer. However after it failed for the first time they just keep sending the same message to the console but then even changing the permissions doesn't seem to help as mv just locks it once it has failed to get ar to work I assume?

So

I dabbled a bit into the whole how to request permissions and how to react to the result thing but what i figured out is basically that it wont work as browsers differ a lot in what they present to the brwoser and espacially in AR the checks arent really there, but as there is some permission given which can be edited in the browser there should be some list available that can be printed out? There is a list of some permissinons that can be requested using the permissionsAPI But at some point I didn't get any further.

And for the blob thing I can try to get a seperate repo done and some screenshots but the people with the devices that failed are on vacation atm so it could take some time. However i will then open a seperate issue. I dabbled a bit with it and I assume it is an issue with the way most materials are displayed. If i had to guess it's a stupid issue with meshStandardMaterial and meshBasicMaterial, as glowing thing where displayed in the proper color but this if for devices hitting the 5 year mark. The current solution is to just not display any of the mv stuff to devices of that age. (Everything below android 10 IoS 14 and IpadOS 13 are cut out there might be better versions to include more devices but this works in our case)