Bug 239135 – WKWebView false positive when testing a.relList.supports("ar"), fails to open USDZ in AR QuickLook

• Status: REOPENED
• Component: New Bugs

[Miles]

When testing for AR support within a WKWebView, a.relList.supports("ar") will return true even if the current WKWebView does not handle viewing USDZ files in AR QuickLook.

For example, open the Apple AR QuickLook gallery (https://developer.apple.com/augmented-reality/quick-look/) inside the Facebook / Instagram / LinkedIn native iOS apps (a non-exhaustive list of example apps).

All these apps open external web links in a WKWebView implementation.

All will report a.relList.supports("ar") as true.

However, clicking on <a> tags set with rel="ar" will result in erroneous behaviour, rather than opening the linked USDZ in AR Quick Look.

LinkedIn app attempts to display the USDZ as text.

Instagram app appears to start loading something (visible progress bar along top of page), but never resolves, never displays the USDZ in AR QuickLook. 

Facebook app declares a 'network error' (!).

This makes feature detection unreliable and redundant. 

Ideally, USDZs opened from WKWebView would *always* work and open in AR QuickLook, regardless of app implementation. 

Or, a.relList.supports("ar") in WKWebView should *only* return true if the app has specifically implemented handling USDZ / AR QuickLook.

[Radar WebKit Bug Importer]

<rdar://problem/91798041>

[Antoine Quint]

I think this only requires a check for the runtime setting in HTMLAnchorElement::relList().

[Antoine Quint]

Pull request: https://github.com/WebKit/WebKit/pull/294

[Miles]

Thanks Antoine, for looking at this. 

Just to add more detail to this issue...

It's worth noting that some apps *do* support opening USDZ files into AR QuickLook from, I think, a WKWebView. 

iOS Chrome, iOS Edge, iOS Firefox all use WKWebView for browser rendering (I think). In these apps, a.relList.supports("ar") returns true, and they do indeed open USDZ files correctly in AR QuickLook. 

Just wanted to make sure that true positive scenario still works. 

Thanks.

[EWS]

Committed r292923 (249690@main): <https://commits.webkit.org/249690@main>

Reviewed commits have been landed. Closing PR #294 and removing active labels.

[Miles]

Hi. Did this fix ship with iOS 15.5?
I'm still seeing false positives in a variety of apps in iOS 15.5.

[Antoine Quint]

No, this did not make iOS 15.5. However, it did ship in the iOS 16 developer seed made available last week.

[Miles]

(In reply to Antoine Quint from comment #7)
> No, this did not make iOS 15.5. However, it did ship in the iOS 16 developer
> seed made available last week.

Amazing. Thanks for confirming. I'll look for it there. Cheers.

[Miles]

(In reply to Antoine Quint from comment #7)
> No, this did not make iOS 15.5. However, it did ship in the iOS 16 developer
> seed made available last week.

Hi Antoine. 

I'm testing this fix on iOS 16.0 Beta (20A5312j) and now seeing false *negatives* with some instances of a.relList.supports("ar"). 

Specifically, this now breaks in iOS Chrome, Firefox, Edge.

For example:

- Returns TRUE in Safari. GOOD - AR QuickLook is indeed supported.

- Returns TRUE in SFSafariViewController. GOOD - AR QuickLook is indeed supported.

- Returns FALSE in Facebook, Instagram, LinkedIn in-app browsers. GOOD - these in-app browsers use basic WKWebView implementation and do not support opening USDZ files in AR QuickLook.

But...

- Returns FALSE in iOS Chrome, Firefox, Edge, DuckDuckGo browser apps (possibly more). BAD - these third-party browsers, built on WKWebView, have gone the extra mile and do in fact support opening USDZ files in AR QuickLook.

Also...

- Returns FALSE in iOS Opera and Brave browser apps (possibly more). GOOD - these third-party browsers, also built on WKWebView, have not implemented AR QuickLook support. 


So although this fix has indeed removed the false positive for WKWebViews, it's too aggressive and now gives false negatives for apps that have implemented AR QuickLook support in their WKWebViews. 

Is there some other way to detect AR QuickLook support for those WKWebViews that have implemented it?

Or, is there something else third-party browser developers need to do to indicate AR QuickLook support in their WKWebViews?

Many thanks for your time.

[Miles]

(In reply to Antoine Quint from comment #7)
> No, this did not make iOS 15.5. However, it did ship in the iOS 16 developer
> seed made available last week.

Retesting this in iOS 16.0 Public Beta 2 (20A5328h) in Chrome 105.0.5195.19 beta.

a.relList.supports("ar") still returns FALSE even though Chrome supports viewing USDZ files.

This is a breaking change that will affect many sites.

Please advise if there is an alternative solution. 

Thanks

[Ali Juma]

(In reply to Miles from comment #10)
> (In reply to Antoine Quint from comment #7)
> > No, this did not make iOS 15.5. However, it did ship in the iOS 16 developer
> > seed made available last week.
> 
> Retesting this in iOS 16.0 Public Beta 2 (20A5328h) in Chrome 105.0.5195.19
> beta.
> 
> a.relList.supports("ar") still returns FALSE even though Chrome supports
> viewing USDZ files.
> 
> This is a breaking change that will affect many sites.
> 
> Please advise if there is an alternative solution. 
> 
> Thanks

In order for WebKit to report the correct value here, we need a way for embedders like Chrome to tell WebKit that they've added logic to download USDZ files and display them using QLPreviewController.

[Dean Jackson]

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" attribute 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).

[Dean Jackson]

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" attribute 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).

[Antoine Quint]

Should this be closed?