The view in your space button doesn't seem to work inside an iframe on iOS Chrome or Firefox

[viperphase1]

I have a page with the model-viewer and attempted to embed it in a website with an iframe. It has been brought to my attention that quicklook fails to launch from within an iframe when viewing the site on iOS Chrome or Firefox (could be a problem in other non-safari browsers too). I already looked at #3626. I'm certain this a different issue.
Instead of launching quicklook I get a failed request for the usdz file: "Refused to display {url_to_usdz} in a frame because it set 'X-Frame-Options' to...
My best guess is that the anchor tag that is supposed to trigger quicklook is instead triggering a navigation on the iframe. As in the iframe src changes to the usdz url.
I imagine this is something for Apple to fix but I wanted to make sure the model-viewer community is aware of this. Beyond alerting the community I'm also reaching out for advice if anyone knows a workaround or a fix. Additional details about the problem would also be appreciated.

[elalish]

I don't believe Firefox launches Quick Look at all. I don't think I've tried iOS Chrome AR inside of an iframe either. I'd recommend making some simple Glitches (feel free to share them here!) to try different permutations. We'd love to know what you find, and we may be able to get an iOS Chrome bug fixed if there's a clear repro.

[milesgreen]

From my experience, opening AR QuickLook from ModelViewer in iFrame is possible in iOS Safari, iOS Chrome and iOS Firefox (yup, even Firefox).

Check out this demo:
https://modelviewer-extended-params.glitch.me/parent.html

You can turn on/off Auto USDZ and a range of QuickLook parameters. Try it in and out of the iFrame.

With iOS 17.4.1:

• Safari and Chrome can handle both USDZ files and auto generated USDZ blobs in and out of iFrame.
• Firefox cannot handle auto generated USDZ blob (regardless of iFrame) but can open USDZ file from iFrame.

So there may be some other issue at play. Possibly a cross origin issue.

@viperphase1:

• What iOS / Browser / ModelViewer versions are you observing this in?
• Are the child and parent HTML pages both on same domain?
• Are the child and parent HTML pages both HTTPS?
• Are you using Auto USDZ or loading a USZD file?

[viperphase1]

@elalish @milesgreen

I reproduced the issue again just now with an iPhone 13 running iOS 17.4.1. The version of Chrome I have installed is 123.0.6312.52. This is the url I'm using to get the model-viewer code: https://ajax.googleapis.com/ajax/libs/model-viewer/3.4.0/model-viewer.min.js

I made some glitches to demonstrate the issue.

This first one has the model viewer. It is able to open the usdz just fine on iOS Chrome.
https://obtainable-yielding-kumquat.glitch.me/

This one has an iframe pointing to the previous glitch:
https://whispering-zesty-game.glitch.me/

When I click the view in your space button in the second glitch the iframe goes blank and quicklook is never engaged

I did discover that if the usdz is served from glitch's cdn it works. In the glitch I created, the usdz is sourced from https://developer.apple.com/augmented-reality/quick-look/models/nike-air-force/sneaker_airforce.usdz

I'm not an expert on iframes so correct me if I'm wrong but I feel like if quicklook can open the usdz from the top context it should also be able to open it from an iframe. The url to the usdz has not changed.

At the very least the iframe shouldn't be wiped.

[milesgreen]

@viperphase1 - I can see from your example, the USDZ file from developer.apple.com domain, has the HTTP header of X-Frame-Options set to SAMEORIGIN.

This specifically prevents the USDZ file from being loaded into an iFrame on another domain. This means the iFrame content and all the iFrame ancestors (the parent pages) must be on the same domain as the USDZ.

It just so happens, iOS Safari is yet to fully implement X-Frame-Options support. So your cross-domain iFrame example works in Safari.

Chrome and Firefox both respect X-Frame-Options, so are preventing the loading of the USDZ file.

So I would check where your actual USDZ files are being served from and make sure that HTTP X-Frame-Options is not configured to SAMEORIGIN or DENY, which would block loading the USDZ into iFrames embedded on other domains.

More info on X-Frame-Options here:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options

[viperphase1]

One solution is to add target="_top" to the quicklook anchor tag. That works even with a cross domain usdz url.
@milesgreen I hear what you are saying about the X-Frame-Options header. So quicklook is operating within the iframe? I assumed that quicklook exists outside the browser and so it shouldn't matter where quicklook was triggered.

[milesgreen]

Interesting that target="_top" would circumvent. I can kind of see how.

QuickLook does exist outside of the browser. But, per my understanding, the browser is handling the original request to retrieve the USDZ file, and so is bound by browser rules. Once the browser establishes that it's handling a USDZ file, it hands it off to QuickLook.

Also, 3rd party browsers are slightly different to Safari in that they use a WKWebView component to render web content. Which is not automatically compatible with QuickLook. The 3rd party browser developers have to specify how to handle USDZ files and hand off to QuickLook. Hence some variation in support.

Also, something to try - if you use Auto USDZ generation, whereby ModelViewer generates a USDZ blob from the GLB file rather than loading a USDZ file, you would also probably circumvent the X domain issue.