Bug 162385 – iOS 10 breaks Construct 2-made UIWebView Cordova apps

• Status: RESOLVED
• Resolution: INVALID
• Component: DOM

[Ashley Gullen]

iOS 10's UIWebView adds the global "indexedDB" property. In iOS 9, the presence of this was the de-facto way to detect WKWebView since it was missing in UIWebView (e.g. see here: http://stackoverflow.com/a/30495399/177222). Now in iOS 10 all the apps built with UIWebView detect that they are WKWebView due to the addition of "indexedDB". Due to various bugs and changes in the security model of WKWebView, we had to make some fairly significant changes to our engine to support it (see: https://www.scirra.com/blog/ashley/25/hacking-something-useful-out-of-wkwebview). When UIWebView apps detect as WKWebView and apply our hacks, they fail to start up. Therefore there are now many iOS apps made with Construct 2 that no longer work on iOS 10.

I don't even know how we can work around this in the short term since in iOS 10, UIWebView and WKWebView appear to be identical to any kind of Javascript detection.

Ideas that could fix this:
- add an easy way to detect WKWebView from Javascript that will be robust across iOS releases, so we can update our framework then get everybody to re-publish their apps
- remove indexedDB from UIWebView so the de-facto detection that has been used for iOS 9 continues to work (should fix existing apps without any republishing)
- do both but then add indexedDB back to UIWebView for iOS 11, which should be enough time for all the updates and app re-publishing to happen

[Brady Eidson]

(In reply to comment #0)
> iOS 10's UIWebView adds the global "indexedDB" property. In iOS 9, the
> presence of this was the de-facto way to detect WKWebView since it was
> missing in UIWebView 

It's unfortunate that using web feature detection was ever used to determine anything about the native environment.

This was never an appropriate strategy.

> - remove indexedDB from UIWebView so the de-facto detection that has been
> used for iOS 9 continues to work (should fix existing apps without any
> republishing)

Adding UIWebView support for IndexedDB in iOS10 was a feature-level effort that was requested by *many* parties, and there's been much rejoicing that we've added it.

I don't think removing it is in the cards.

[Anders Carlsson]

It should be possible to use a WKUserScript that injects a custom property for WKWebViews, and then the website can check for the existence of that property.

[Alexey Proskuryakov]

This sounds like the answer, moving to INVALID as something to be resolved outside WebKit. Thank you for reaching out!

[Ashley Gullen]

> It's unfortunate that using web feature detection was ever used to determine
> anything about the native environment.

Yes, but we seem to have had no other choice. WKWebView does not identify itself in any way, and we are framework developers, so we don't have any control over the embedding code. So there was no option to detect WKWebView other than rely on the availability of the APIs, which of course is subject to change. Hence my suggestion to make WKWebView identifiable to Javascript in some way.

So I guess we can try and convince WKWebView embedders to make it identifiable to our engine in some way - but some way of identifying WKWebView itself from Javascript seems like it would be more reliable.

[Chris Dumez]

(In reply to comment #4)
> > It's unfortunate that using web feature detection was ever used to determine
> > anything about the native environment.
> 
> Yes, but we seem to have had no other choice. WKWebView does not identify
> itself in any way, and we are framework developers, so we don't have any
> control over the embedding code. So there was no option to detect WKWebView
> other than rely on the availability of the APIs, which of course is subject
> to change. Hence my suggestion to make WKWebView identifiable to Javascript
> in some way.
> 
> So I guess we can try and convince WKWebView embedders to make it
> identifiable to our engine in some way - but some way of identifying
> WKWebView itself from Javascript seems like it would be more reliable.

I still do not understand why framework developers would need to know about their embedder (UIWebView vs WKWebView). If JS features are available in one and not the other then feature detection seems to be the way to go (not embedder detection).

[Brady Eidson]

(In reply to comment #5)
> (In reply to comment #4)
> 
> I still do not understand why framework developers would need to know about
> their embedder (UIWebView vs WKWebView). If JS features are available in one
> and not the other then feature detection seems to be the way to go (not
> embedder detection).

I echo this.

Whatever reasons you *think* you have to do UIWebView/WKWebView detection, let's work through each and either make you comfortable that it's a non-issue or file a separate bug and get it resolved.

[Ashley Gullen]

I wrote it all in this blog post: https://www.scirra.com/blog/ashley/25/hacking-something-useful-out-of-wkwebview

Related bugs are already filed:
https://bugs.webkit.org/show_bug.cgi?id=101671
https://bugs.webkit.org/show_bug.cgi?id=154916

Until that is fixed, we need a way to detect WKWebView to work around the problems/differences compared to UIWebView.

[Brady Eidson]

(In reply to comment #7)
> https://bugs.webkit.org/show_bug.cgi?id=101671

There's zero indication in that bug that it works in UIWebView but not WKWebView - Are you saying that's the case?

> https://bugs.webkit.org/show_bug.cgi?id=154916

I'll comment directly in that bug.

[Ashley Gullen]

(In reply to comment #8)
> (In reply to comment #7)
> > https://bugs.webkit.org/show_bug.cgi?id=101671
> 
> There's zero indication in that bug that it works in UIWebView but not
> WKWebView - Are you saying that's the case?

Sorry, it was a bit of a misleading mention. That bug blocks useful workarounds where we play from a blob URL instead of from a file: path. The blob URL feature is a standard web platform feature, so I think it ought to be supported anyway. But the underlying issue is really just that WKWebView considers every subresource in a Cordova application to be from a separate origin, whereas UIWebView allowed the resources to load. (This is what bug 154916 is about.) Then we have to do a whole pile of workarounds to avoid those restrictions. But we can't know whether to use those workarounds unless we know if we're in WKWebView, which is why I filed this bug.

I'll sort out a minimal testcase for bug 154916.

[Ashley Gullen]

We're looking in to using the presence of window.webkit.messageHandlers to detect WKWebView. Is this a reliable way to do so?

[caroldriscoll33]

We at https://domyhomeworkonline.net/ would appreciate implementation of detecting WKWebView from Javascript. Think that would be helpful.