canActivateAR returns false positive in iOS WKWebView

[milesgreen]

Description

When loading ModelViewer in an iOS WKWebView (EG, Facebook / Instagram / LinkedIn embedded browser), modelviewer.canActivateAR returns a false positive.

canActivateAR returns true, when in actual fact attempting to view a USDZ causes an error (depends on the containing app as to how the error manifests).

By default, WKWebView does not support opening USDZs in QuickLook. But there is a bug whereby testing a.relList.supports("ar") always returns true, regardless if the WKWebView has implemented handling of USDZ.

This makes it impossible to do reliable feature detection and results in the ModelViewer AR button being displayed in a context that it's not compatible with.

Issue is logged on WebKit Bugzilla:
https://bugs.webkit.org/show_bug.cgi?id=239135

Apparently a fix is going in to iOS 16 so that WKWebView will only return true if the WKWebView has been configured (by the containing native app) with SystemPreviewEnabled. It will be interesting to see how it behaves and if it gives a true indication of USDZ support.

Live Demo

View any ModelViewer content inside an iOS WKWebView (EG, Facebook, Instagram, LinkedIn):
https://glitch.com/edit/#!/model-viewer

Version

• model-viewer: v1.12.0

Browser Affected

• Chrome
• Edge
• Firefox
• IE
• [15.5] Safari (WKWebView)

OS

• Android
• iOS
• Linux
• MacOS
• Windows

AR

• WebXR
• SceneViewer
• QuickLook

[milesgreen]

It's worth adding, some iOS apps do support viewing USDZ from WKWebView (EG, Chrome browser) because they went the extra mile to implement support.

[milesgreen]

@grorg - might be of interest. But I think it's being / been dealt with on the Apple side.

[elalish]

I think I'm going to start converting most of these "not model-viewer" issues to discussions, since there's not a lot I can do to track them here.

[milesgreen]

Just testing the fix for this in iOS 16.0 Beta (20A5312j)

Unfortunately, the fix now means that a.relList.supports("ar") will always return false in, apparently, every instance of WKWebView it seems.

This means that modelviewer.canActivateAR is returning false in iOS Chrome, Firefox, Edge browser apps in iOS 16 (as these are built on top of WKWebView).

Meaning that ModelViewer in iOS 16 doesn't display an AR button in those browsers.

I have added these finding to the bugzilla ticket above.

@grorg is on the mailing list for the bugzilla ticket I believe.

Hopefully this'll be ironed out before iOS 16 public.

[milesgreen]

@elalish @grorg

I'm retesting this in the latest iOS 16.0 Public Beta 2 (20A5328h) in Chrome 105.0.5195.19 beta.

Unfortunately a.relList.supports("ar") still returns false even though Chrome does support viewing USDZ files.

This is going to break modelviewer.canActivateAR and prevent ModelViewer showing the AR button in iOS Chrome, Firefox, Edge, etc.

I've not been able to elicit a response from Webkit / Apple so far.

If this isn't rectified, then ModelViewer compatibility checks may need to resort to user agent detection? ☹️

[elalish]

Okay, well it looks like iOS 16 is officially breaking this for launch. @milesgreen Since you've been testing these beta builds, would you be up for making a work-around PR?

[milesgreen]

Ok. I might be able to take a look over the next couple of weeks.

Without any reliable feature detection available, this might come down to user agent checking.

[elalish]

That's fine, you're the one who has been noticing all these issues, so if it works for you, I'm confident it'll be decent for everyone else.

[milesgreen]

PR submitted!
#3784

[grorg]

Yep - we've just become aware of this bug in a.relList.supports("ar"). We'll update here when we have news.

[grorg]

Sorry, I misread the bug.

I believe this is correct behaviour. AR Quick Look is not supported directly in WKWebView clients (this is a bug we want to fix). Some browsers might implement their own code to intercept the navigation and display their own "Quick Look" view, but there is no API for those clients to tell the WKWebView they are doing it.

So from the perspective of the WKWebView, it is correct to say it doesn't support the ar value on rel.

Again, the real solution is to allow all WKWebView clients to support ARQL (that might require some API changes too, based on the hosting UIViewController).

[elalish]

Agreed that putting the support in WKWebView is the right solution. Do you think that'll make it in Safari 16? I guess I'd vote for revert to the old behavior if not. Better to say it works and fail than to exclude browsers where it's working properly.

[grorg]

I'll try to add it to all WKWebViews. This won't be in place for iOS 16, sorry.

[milesgreen]

@grorg - Just wondering...

If you're working on full ARQL support for WKWebView (great!) but this won't be in place for iOS16 (shame, but understandable)...

Is there still a chance / argument to reverting the change to a.relList.supports("ar") in order to retain same behaviour as iOS15 and prior?

For what it's worth, I would vote for, while waiting for full ARQL support in WKWebView, revert a.relList.supports("ar") to maintain status quo of current iOS15 behaviour.

[elalish]

I actually already had this conversation offline; @grorg feels the same way we do, but apparently they missed the window already. Hence my above comment :/

[milesgreen]

Ah... OK.

[milesgreen]

For future reference, this was addressed with: #3784