Model-viewer: AR button is not showed in Safari on iPad Pro on iOS 13

[fselcukcan]

Description

AR button is not showed in Safari on iPad Pro on iOS 13. According to Apple's list of supported devices here down in the page this device has support for AR on Safari.

Live Demo

Browser Affected

• [ ] Chrome
• [ ] Edge
• [ ] Firefox
• [ ] Helios
• [ ] IE
• [X] Safari

OS

• [ ] Android
• [X] iOS
• [ ] Linux
• [ ] MacOS
• [ ] Windows

Versions

• model-viewer: v0.6.0
• three.js: r105

[cdata]

@fselcukcan thanks for the report. Could you share a link to a demo that exhibits this behavior for you, or else paste the <model-viewer> HTML you are using so we can try to repro ourselves?

[scanblue-sr]

@fselcukcan @cdata The ar-button is not shown anymore because the test :
const IS_IOS = /iPad|iPhone|iPod/.test( navigator.userAgent ) && !self.MSStream;
fails on iPads with iOS 13/iPadOS 13 Beta.

see:
https://stackoverflow.com/questions/57599945/how-to-detect-ios-13-on-javascript
https://stackoverflow.com/questions/57765958/how-to-detect-ipad-and-ipad-os-version-in-ios-13-and-up

Edit:
Safari on these iPads requests the desktop websites by default. If you change this behaviour in the Safari settings it's working again.

[freinbichler]

iPadOS 13 will be released to the public on September 30th, so it would be amazing if this fix could make it into the next release to avoid model-viewer's AR feature breaking on every iPad.

[cdata]

@scanblue-sr ahh, thanks for the added details.

@freinbichler acknowledged, we'll try to get this in to v0.7.0 which should go out before the end of the month.

[cdata]

FYI while I do think we'll have v0.7.0 before the end of the month, we will also be back-porting this fix and releasing it as v0.6.1 for the benefit of folks who won't be able to update to v0.7.0 right away.

[cdata]

Re-opening, as it appears that the logic in our fix was wrong. A new fix should go out later today.

[cdata]

FYI v0.6.2 has been released including the updated fix for this issue.

[fselcukcan]

@scanblue-sr @cdata Instead of testing the user agent I have an idea of a feture detection as this so it works even if the mentioned iPad user agent string looks like a desktop browser. In my experience it had nothing like iPad thus failing the regexp test above. It had Macintosh in it instead.
So I have wrote the following function:

function doesSupportAnchorRelAR() {
  return document.createElement("a").relList.supports("ar");
}

after research and finding that: https://webkit.org/blog/8421/viewing-augmented-reality-assets-in-safari-for-ios/

[cdata]

@fselcukcan as I mentioned in another conversation , we already perform this test. Unfortunately, this test will be true for both Chrome and Safari on iOS, but in some versions of Chrome the behavior is different (this is why we have the quick-look-browsers attribute, to allow folks to opt-out of Chrome specifically).

That said, it's possible that you're right that we could skip the user agent detection at this point. We just need to make sure that we don't have any false positives where browsers _do_ support rel="ar" but have different behavior from iOS Safari.

[fselcukcan]

I see now all the things about Content-Type header requirement. But I do not see practicality of opting out of it in Chrome on iOS. Since there is no ARCore as there is in Android, Chrome can only make use of Quick Look.

[cdata]

@fselcukcan the reason why is because Chrome on iOS is able to launch Quick Look. Quick Look is a separate app, not a part of the web, and not part of Safari (the same goes for Scene Viewer on Android). The problem is that on some versions of Chrome on iOS, there is an extra requirement that is very hard for some folks (setting the Content-Type header). This is why we have an opt-in approach, because otherwise we would display the AR button and instead of launching Quick Look the file would just download in many cases.

[fselcukcan]

I see now. Thank you for detailed explanation again.