Bug: viewing .usdz in Chrome breaks every time

[Lavosbit]

Description

I'm using glitch.com to view/test my model-viewer scenes and have been for a couple of years. While testing my most recent project I noticed that I'm getting a strange crash every time I am trying to view the AR model in iOS when using Chrome. I assumed it was a user error but then even tested the google animals that are using modelviewer as well as the models straight from modelviewer.dev in chrome. The same scenes work as expected in Safari.

This bug can be reproduced by using Chrome on iOS and attempting to view an AR asset in preview. (Not sure if this matters but I'm using iOS 15.4)

Example File

https://glitch.com/~anasazi-raven-and-pot

Loom Recording

https://www.loom.com/share/9f02e8a3486a4f2aaf8e27a896b49010

Screenshots

The following screenshots were taken from attempting to view models on modelviewer.dev in AR using Chrome iOS:

Loom Recording

https://www.loom.com/share/9f02e8a3486a4f2aaf8e27a896b49010

Version

• model-viewer: v1.10.1

Browser Affected

• Chrome, version: 99.0.4844.59
• Edge
• Firefox
• IE
• Safari

iOS

• Android
• iOS
• Linux
• MacOS
• Windows

AR

• WebXR
• SceneViewer
• QuickLook

[Ocupe]

I have observed the same bug in my app. QuickLook worked for iOS Chrome and iOS Firefox before the update to iOS 15.4. Now it only works for Safari on 15.4.

Before the update to iOS 15.4, I was able to get QuickLook working on iOS Chrome and iOS Firefox with the help of this issue comment from issues/1796. Maybe helpful because it seems that the .usdz file is interpreted as a text file again.

[milesgreen]

Can confirm here too. On iOS 15.4 iPhone 12 Pro, trying to open USDZ in Chrome, Firefox results in page of text.

[milesgreen]

Having done some digging, I found this chrome bug report:

https://bugs.chromium.org/p/chromium/issues/detail?id=1302551&q=USDZ&can=2

Where there is a discussion about Content-Disposition header.

In some initial tests, when I set the USDZ file to be served with header Content-Disposition: attachment
the following is observed:

• iOS Safari - opens AR QuickLook
• iOS Chrome - opens AR QuickLook 🎉
• iOS Firefox - opens page of text 😕
• iOS Edge - opens AR QuickLook 🎉
• iOS Opera - opens a file download dialog 😕

[Ocupe]

I can confirm @milesgreen findings (thanks for sharing) for:

• iOS Safari - opens AR QuickLook
• iOS Chrome - opens AR QuickLook 🎉
• iOS Firefox - opens page of text 😕

and that serving USDZ files with an Content-Disposition: attachment header fixed AR QuickLook on iOS Chrome for me.

[AdrianTabacaru]

Hey, can you share the fix for a beginner please?
Thanks!

[Ocupe]

@AdrianTabacaru my .htaccess file looks like this:

<FilesMatch ".+\.(usdz)$">
    Header set Content-Type "model/vnd.usdz+zip"
    Header set Content-Disposition "attachment"
</FilesMatch>

The Header set Content-Type "model/vnd.usdz+zip" row fixed Problems with iOS-Firefox and iOS-Chrome on iOS < 15.4

[AdrianTabacaru]

Thank you for your answers. My .htacces files was empty, I've been trying both:
<FilesMatch ".usdz$"> Header set Content-Disposition: attachment

or

<FilesMatch ".+.(usdz)$">
Header set Content-Type "model/vnd.usdz+zip"
Header set Content-Disposition "attachment"

refreshed the page on the phone and still ASCI text appears on my iPhone iOS 15.4
What am I doing wrong?

Thank you!

[AdrianTabacaru]

Can you guys confirm that accessing this page works on your iOS 15.4 ?
For me it worked on the previous iOS version but after update I get ASCII when pressing the "View in your space button" that should open the AR camera.

Thank you!

[AdrianTabacaru]

Hey sorry, that was a mistake in the previous post, I didn't paste "code" just plain text.
The .htacces file on the root folder on my webpage is pasted correctly:
<FilesMatch "\.usdz$"> Header set Content-Disposition: attachment </FilesMatch>
but still has the ASCII response on my phone :-)
Shoul it need more time to propagate? I have no idea :-(
Thanks!

[AdrianTabacaru]

Much more weird is that the official webpage has the same ASCII response behavior on my phone.
https://modelviewer.dev/
and yes, it's a typo on the post not on the website root :-)

[AdrianTabacaru]

I confirm this was fixed using this code:
<FilesMatch ".+\.(usdz)$"> Header set Content-Type "model/vnd.usdz+zip" Header set Content-Disposition "attachment" </FilesMatch>
in the .htaccess file

Now, I have multiple .htaccess files, one is located on root, one is on public_html folder and another one is in the folder where the .usdz and the .html files sit. I don't know which one does the job, putting it only on root doesn't seem to fix it in the beginning for me.
Also, after making it to work, I have deleted all the .htaccess files on all the folders including the root, deleted the cache on my phone and it looks like now it works without that file. Or maybe tha cache wasn't completely deleted...
Anyway I will put one .htaccess file on root as @Ocupe suggested and I will post here if everything works smoothy.

Thank you @Ocupe and @charpstar for the code and everyone for your support!
Cheers!
Adrian

[ghost]

@Lavosbit hello! Excuse me, were you able to get it to work on Glitch? Thanks!

[milesgreen]

I think this issue may have been patched somewhere along the way with Chrome 100.
I'm testing on iOS 15.5 beta (19F5047e), Chrome 100.0.4896.77.

[elalish]

Thanks for sharing @milesgreen! I'm going to close this to let others know. Please post if you need me to reopen.

[milesgreen]

Sooo... I did some more thorough testing. It appears this is in fact still an issue, even with Chrome 100 in iOS 15.4.1. In this instance, even with Chrome 100 but without the Content-Disposition: attachment HTTP header, Chrome will still attempt to display USDZ in-line as text.

But in iOS 15.5 (beta 1 and 2), this is no longer an issue in Chrome, and even without the Content-Disposition: attachment HTTP header, Chrome will display USDZ properly via QuickLook.

So for now, folks may want to keep adding Content-Disposition: attachment, as iOS 15.4 will be around a little while longer.

[orgaralf]

Ran into the problem myself today with Chrome 100+ on iOS 15.4.1, added the header and it works in both (Safari and Chrome) on iOS fine now... thanks for the help, folks!

[elalish]

From iOS-Chrome, it sounds like they are planning to have this fix go into Chrome 102.

[mimeeq-neal]

Hi all.

We noticed that although it works with the revised headers it caused a 2nd issue that I don’t see anyone else spotted yet which is that if you go to a model and load it on chrome iOS. Then close the ar view (camera), then again launch it, it does not load.

By contrast works fine on safari iOS.

Here is a demo https://mimeeq.com/3ddemo?variantCode=HAOM%3DSeatFinishes-b3%26BaseFinishes-a7%26OwnMaterial-%26UploadCustomerMaterial-&arShortCode=E8EJY6TI on our website but I see other sites have exactly the same issues.

[milesgreen]

@mimeeq-neal
Trying to replicate your issue of repeat launches.
This might have already been fixed along with a number of other fixes in Chrome 102 (see below).
I'm trying to replicate this on iOS 15.4.1, Chrome iOS 102.
Repeat launches is working fine.

[mimeeq-neal]

@milesgreen i can confirm that it now works after installing chrome iOS 102
Life is back to normal :)
Thanks for the reply.

[milesgreen]

iOS Chrome 102 is now live: https://chromereleases.googleblog.com/2022/05/chrome-for-ios-update.html

Testing on iOS 15.4.1 (to be conservative, even though iOS 15.5 is now live), this seems to have fixed a lot of related issues:

• Now, even without Content-Disposition: attachment HTTP header, viewing USDZ models will open in AR QuickLook rather than display inline text
• Also, with the Content-Disposition: attachment HTTP header, viewing USDZ models will still open in AR QuickLook
• Fixed scaling (which appends #allowsContentScaling=0 to USDZ path) is respected and the model scale is locked in AR QuickLook
• BONUS: Auto USDZ generation as blob now works in Chrome v102 🎉 (although additional #parameters after blob don't yet work).