Closed msub2 closed 2 years ago
Thanks for reporting. Tell us about your findings with the Third Axis crew. It'd be awesome if they could adopt a different solution than checking the UA (a bad policy in general). In case of not having a server side fix I guess we could always tune the UA for that site...
This is actually the full check that happens on the page:
window.mobileCheck = function() {
let check = false;
(function(a){if(/(android|bb\d+|meego).+mobile|avantgo|bada\/|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(hone|od)|iris|kindle|lge |maemo|midp|mmp|mobile.+firefox|netfront|opera m(ob|in)i|palm( os)?|phone|p(ixi|re)\/|plucker|pocket|psp|series(4|6)0|symbian|treo|up\.(browser|link)|vodafone|wap|windows ce|xda|xiino/i.test(a)||/1207|6310|6590|3gso|4thp|50[1-6]i|770s|802s|a wa|abac|ac(er|oo|s\-)|ai(ko|rn)|al(av|ca|co)|amoi|an(ex|ny|yw)|aptu|ar(ch|go)|as(te|us)|attw|au(di|\-m|r |s )|avan|be(ck|ll|nq)|bi(lb|rd)|bl(ac|az)|br(e|v)w|bumb|bw\-(n|u)|c55\/|capi|ccwa|cdm\-|cell|chtm|cldc|cmd\-|co(mp|nd)|craw|da(it|ll|ng)|dbte|dc\-s|devi|dica|dmob|do(c|p)o|ds(12|\-d)|el(49|ai)|em(l2|ul)|er(ic|k0)|esl8|ez([4-7]0|os|wa|ze)|fetc|fly(\-|_)|g1 u|g560|gene|gf\-5|g\-mo|go(\.w|od)|gr(ad|un)|haie|hcit|hd\-(m|p|t)|hei\-|hi(pt|ta)|hp( i|ip)|hs\-c|ht(c(\-| |_|a|g|p|s|t)|tp)|hu(aw|tc)|i\-(20|go|ma)|i230|iac( |\-|\/)|ibro|idea|ig01|ikom|im1k|inno|ipaq|iris|ja(t|v)a|jbro|jemu|jigs|kddi|keji|kgt( |\/)|klon|kpt |kwc\-|kyo(c|k)|le(no|xi)|lg( g|\/(k|l|u)|50|54|\-[a-w])|libw|lynx|m1\-w|m3ga|m50\/|ma(te|ui|xo)|mc(01|21|ca)|m\-cr|me(rc|ri)|mi(o8|oa|ts)|mmef|mo(01|02|bi|de|do|t(\-| |o|v)|zz)|mt(50|p1|v )|mwbp|mywa|n10[0-2]|n20[2-3]|n30(0|2)|n50(0|2|5)|n7(0(0|1)|10)|ne((c|m)\-|on|tf|wf|wg|wt)|nok(6|i)|nzph|o2im|op(ti|wv)|oran|owg1|p800|pan(a|d|t)|pdxg|pg(13|\-([1-8]|c))|phil|pire|pl(ay|uc)|pn\-2|po(ck|rt|se)|prox|psio|pt\-g|qa\-a|qc(07|12|21|32|60|\-[2-7]|i\-)|qtek|r380|r600|raks|rim9|ro(ve|zo)|s55\/|sa(ge|ma|mm|ms|ny|va)|sc(01|h\-|oo|p\-)|sdk\/|se(c(\-|0|1)|47|mc|nd|ri)|sgh\-|shar|sie(\-|m)|sk\-0|sl(45|id)|sm(al|ar|b3|it|t5)|so(ft|ny)|sp(01|h\-|v\-|v )|sy(01|mb)|t2(18|50)|t6(00|10|18)|ta(gt|lk)|tcl\-|tdg\-|tel(i|m)|tim\-|t\-mo|to(pl|sh)|ts(70|m\-|m3|m5)|tx\-9|up(\.b|g1|si)|utst|v400|v750|veri|vi(rg|te)|vk(40|5[0-3]|\-v)|vm40|voda|vulc|vx(52|53|60|61|70|80|81|83|85|98)|w3c(\-| )|webc|whit|wi(g |nc|nw)|wmlb|wonu|x700|yas\-|your|zeto|zte\-/i.test(a.substr(0,4))) check = true;})(navigator.userAgent||navigator.vendor||window.opera);
console.log(check)
return check;
};
mobileCheck();
if(mobileCheck()){
document.getElementById('model').removeAttribute('shadow-intensity')
document.getElementById('body').style.backgroundSize = "fit"
}else {
document.getElementById('mobile_enter').style.display = ""
document.getElementById('body').style.backgroundSize = "fit"
document.addEventListener('wheel', function(e) {
console.log(e)
});
};
var str = navigator.userAgent;
if(str.includes('Oculus')){
document.getElementById("enter").innerHTML = "Enter VR"
}
window.addEventListener('DOMContentLoaded', (event) => {
var str = navigator.userAgent;
if(str.includes('Instagram')){
document.getElementById('ar_text').innerHTML = "Open In Safari"
document.getElementById('insta_banner').classList.remove('hidden')
document.getElementById('ar_text').classList.remove('border-white')
document.getElementById('ar_text').classList.add('hidden')
}
})
As you can see it actually explicitly checks for Oculus in the user agent before loading the Enter VR button. They are aware of the issue now, just not sure when they'll actually get around to addressing it.
Yeah I saw the JS too. Actually the issue is not only claiming to be Oculus. In order for the button "Enter VR" to show the "Android" part of the UA needs to be removed too, because otherwise we wouldn't pass the mobileCheck()
. With those 2 changes the "Enter VR" button appears.
WRT the performance it's indeed not good enough, we'd have to check that but Gecko is known for a not so good WebGL performance.
Hey thanks for going through all of this :) - the user agent issue will be fixed in the newest version of Obscura. As far as the performance issues, is Wolvic using the same version of the WebXR API that the Oculus Browser is using? Please correct me if I'm wrong but the last version of Firefox reality that I tested was using the WebVR api instead of the newer WebXR API. Is that still the case?
Hey thanks for going through all of this :) - the user agent issue will be fixed in the newest version of Obscura. As far as the performance issues, is Wolvic using the same version of the WebXR API that the Oculus Browser is using? Please correct me if I'm wrong but the last version of Firefox reality that I tested was using the WebVR api instead of the newer WebXR API. Is that still the case?
That's awesome, looking forward to the new version.
Regarding WebXR yes, Wolvic supports WebXR indeed. WRT WebVR we have dropped the support as it's deprecated and it'd be too much work to support both.
Awesome to hear. Thank you for clarifying that. Regarding your previous comments:
"WRT the performance it's indeed not good enough, we'd have to check that but Gecko is known for a not so good WebGL performance."
Is this something that I can assume and include in our device detection process? Almost every different platform supports WebGL and WebXR API in a different way. Knowing the limitations of Wolvic would be very helpful so we can build in responsive changes that makes the user experience in Wolvic better.
For example, in the current build of Obscura, there is a dynamic light that produces a shadow on the floating clock in the main-hall on desktop. If you view the scene in VR we remove the dynamic light to improve FPS and overall performance.
If we can pin-point the things to avoid in Wolvic I'd be happy to include it in our device detection process.
"It'd be awesome if they could adopt a different solution than checking the UA (a bad policy in general). "
I'm curious, how would you recommend understanding what device a user is visiting the page on without the user agent string? Open to adopting a better practice but at the moment I've found this to be pretty much the only way to do it.
Understanding the user device is crucial given the fragmented support of the WebXR API.
For example, when Third Axis links to our work in Instagram or Twitter posts and a user views it via the in-app browsers (webkit) inside of instagram and twitter, USDZ content is blocked from loading. We use the user-agent to detect instagram/twitter, and show a banner that says 'please view this in safari" so that users can actually view things in AR.
Checking the UA string is (and has been) generally a bad idea for a variety of reasons. Among other things it basically breaks the universal accessibility of the web and the web standards. I've worked on browser engines for more than a decade now, and we've had to add specific quirks for many sites tons of times even changing them over time. Our users were suddenly forbidden to access some sites just because there were changes in the server side wrt the UA filtering. In the end, if you think about it, web browsers end up pretending to be some others so the ultimate purpouse of UA filtering does not work.
Not only that but trying to get information from UA is also a very hard problem which usually leads to issues like the ones we have in Wolvic (we claim to run on Android so we're filtered out because the server thinks we're on a mobile phone). Also it's super easy to fake the user agent (can be done in Wolvic with a Firefox extension without building from sources).
Summarizing a lot instead, of using UA filtering is way much better to look for specific features you might need. There are plenty of resources in the web to check that, but the one I've always found more interesting is this one from Mozilla https://developer.mozilla.org/en-US/docs/Web/HTTP/Browser_detection_using_the_user_agent
Hope it helps
Thank you for breaking this all down. Will try and remove the user-agent filtering as much as possible in the newest builds of Obscura.
This should work in the next release. XR experience is not great though. Looks like the 3D models are very expensive to render in some devices (like Huawei glasses)
Configuration
Wolvic version: 0.9 Wolvic build ID: d8f85016 (AC 63.0.0)
Hardware: Oculus Quest 2 v37
Steps to Reproduce
Current Behavior
Obscura does not detect immersive-vr capabilities and performs very poorly in the actual app.
Expected Behavior
Site should detect capability and perform at an optimal framerate similar to Meta Browser.
Possible Solution
I've determined that the reason it is not displaying the "Enter Experience" button on the homepage is due to a mobile user agent check by Obscura that appears to exclude all Android/mobile devices besides Oculus/Meta devices. I'll pass this along to the team members at Third Axis. I am unsure what is causing the poor performance. I would need to set up remote debugging and dig into it some more from there.