Anyone have sample code (playground?) of a really graceful way of falling back if someone is expecting an AR immersive session to load but it can’t because for instance #SafariIsTheNewIE, FF requires an addon, Chrome requires ARToolKit + chrome’s incubation flags set for full features. In short, even 5? years after the standard, support is poor at best.
Right now Babylon will spit out a console warn Session mode “immersive-ar” not supported in browser
Then, hide the AR launch button.
In the playgrounds “nothing” happens right now in these cases except the session can become unusable if it is expecting AR features. Though fine for a playground demo meant to show a single feature of example, in practical use cases this is really poor UX.
WebXR support is real wonky across browsers as you’ve noticed! Making things even more fun is trying to hit the moving targets of feature support - as you also noted. Because there’s so many different combinations of ways things can go right/wrong, the UX as a whole is up to the app developer. That’s not to say you won’t have any help!
BJS has the WebXRExperienceHelper and the WebXRFeatureManager (IIRC that’s the names…) to abstract a ton of the messy details involved in feature detection and graceful degradation. You tell it what features you’d like to use and then subscribe to various Observables that fire when/as features are loaded and initialized - it will attempt to polyfill unsupported features and/or API’s so that the end result is that only a small surface area of your code needs to accommodate the vagaries of WebXR.
