<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED INVALID - iOS 10 breaks Construct 2-made UIWebView Cordova apps"
href="https://bugs.webkit.org/show_bug.cgi?id=162385#c5">Comment # 5</a>
on <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED INVALID - iOS 10 breaks Construct 2-made UIWebView Cordova apps"
href="https://bugs.webkit.org/show_bug.cgi?id=162385">bug 162385</a>
from <span class="vcard"><a class="email" href="mailto:cdumez@apple.com" title="Chris Dumez <cdumez@apple.com>"> <span class="fn">Chris Dumez</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=162385#c4">comment #4</a>)
<span class="quote">> > 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.</span >
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).</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>