Model-viewer: iOS Quick Look - make sure that it works as expected, and that the caveats outlined here are documented in the README

[jsantell]

Meta bug, can break out if not handled here. Taken from current readme:

• [ ] There is currently no way to tell whether an iOS device has AR Quick Look support. Possibly check for other features added in Safari iOS 12 (like CSS font-display): https://css-tricks.com/font-display-masses/ Are there any better ways?

• [ ] Since there are no USDZ three.js loaders (and seems that it'd be difficult to do), Safari iOS users would either need to load a poster image, or if they load the 3D model content before entering AR, they'd download both glTF and USDZ formats, which are already generally rather large. Not sure if this is solvable at the moment, so we may need to just document the caveats.

• [ ] With native AR Quick Look, the entire image triggers an intent to the AR Quick Look. Currently in this component implementation, the user must click the AR button. Unclear if we want to change this, as interacting and moving the model could cause an AR Quick Look trigger. Do we want this to appear as native as possible?

• [ ] The size of the AR Quick Look native button scales to some extent based off of the wrapper. We could attempt to mimic this, or leverage the native rendering possibly with a transparent base64 image. I've played around with this, but someone with an OSX/iOS device should figure out the rules for the AR button size. I did some prelim tests here: https://ar-quick-look.glitch.me/

[cdata]

We could probably leverage Page Visibility API to do this detection in a somewhat x-platform compatible way.

Here is an example of a page that invokes an Android intent and waits to see if the tab has become "hidden": http://model-tag-experiments.glitch.me/intents/
You can toggle the checkbox to test what happens when an unhandled intent is triggered.
The results of post-intent visibility detection are reported on the page.

[smalls]

Some clarifications (for myself) and some thoughts..

• The reason that we need to know if the system supports Quick Look is so that we can programmatically decide whether or not to display the Quick Look icon. The system does it by default, but only for nested images. As an aside, I've continued to expect that there should be a good answer for how to detect a Quick Look-capable system, but I've been disappointed every single time.
• Documenting the caveats seems appropriate.
• Interacting with the model seems more important then mimicking the native entire-image-enters-AR behavior. It seems like it'll be pretty intuitive if a click on the model interacts with the model, and then user's click the AR icon to enter AR. As an aside, are we OK with the current icons or is there a different set that we can use?

[jsantell]

As an aside, I've continued to expect that there should be a good answer for how to detect a Quick Look-capable system, but I've been disappointed every single time.

Definitely :cry:

• As an aside, are we OK with the current icons or is there a different set that we can use?

Current Quick Look icon is from Apple (SVG) with CSS handling the white circle. In the native iOS icon for the web, this circle applies a slight blur filter that I think I had trouble looking identical. I think this is being applied to both Android and iOS, and a different iteration of this has the Google AR icon when on Android that we can use.

[smalls]

I've filed #44 for a long-term issue to look into what API we should use to discover if the current device supports Quick Look.

[cdata]

This issue seems to have a lot of useful info. I think iOS Quick Look works well enough for public release, but this issue is still relevant to future work, so I'm going to move it back to the icebox.

[mikkoh]

You can check whether AR Quicklook is supported in the browser by doing:

const anchor = document.createElement('a');
const supportsAR = anchor.relList.supports('ar');

We're running this in production at Shopify.