Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of agrieve@google.com designates
 209.85.218.46 as permitted sender)
MIME-Version: 1.0
Sender: agrieve@google.com
In-Reply-To: 
 <CAE6O_-YFrgdd-0zhzoexaUheihXQL8evK77oqeRE+oa-evDsfg@mail.gmail.com>
References: 
 <CAE6O_-axWrCTm5HFXSD=CzFTgzPOgsjU5fAbbeU1ona8e_F1Tg@mail.gmail.com>
 <CAE6O_-YB47Zyo7tqXzEsQ0RPOwrcddbyQSv4ecXCD2ZW+FFJBw@mail.gmail.com>
 <CAE6O_-ap3fVL1XFWZhZC8YKSN_iEWQ-Drtt9E+UjOmXUbS9n0Q@mail.gmail.com>
 <CAPTyS6B7bGLi0wjQ4Z30hc-PDz3k+4VWBXWxqEUPEw1OUu4H=w@mail.gmail.com>
 <CABiQX1UGKX1Xo=pY1LdP8twp2pooUdSg_KhWwVjc0q=e0GKS9g@mail.gmail.com>
 <CAE6O_-YGYEoJqho_xzLYyH+2iNDircSnJBNF_MtVWnMOS29u5g@mail.gmail.com>
 <CAE6O_-YFrgdd-0zhzoexaUheihXQL8evK77oqeRE+oa-evDsfg@mail.gmail.com>
From: Andrew Grieve <agrieve@chromium.org>
Date: Tue, 9 Sep 2014 20:19:27 -0400
Message-ID: 
 <CABiQX1U3t7NbZvB2vtRfZo0PX2UWQLeGv7eYv4SdbLd4F_vKiA@mail.gmail.com>
Subject: Re: [iOS 8] Status of WKWebView work
To: dev <dev@cordova.apache.org>
Content-Type: text/plain; charset=UTF-8

That's great news.

JS execution speed honestly hasn't really been a problem for Cordova
apps that I've heard of anyways.

On Tue, Sep 9, 2014 at 7:01 PM, Shazron <shazron@gmail.com> wrote:
> Some interesting findings - iOS UIWebView and WKWebView have the same
> user-agent value, and both score 440 on html5test.com.
>
> Which makes me think they use the same engine (renderer and js), but
> UIWebView has nitro turned off. WKWebView seems to be about 4x faster on
> the Sunspider benchmark.
>
> On Tue, Sep 9, 2014 at 3:58 PM, Shazron <shazron@gmail.com> wrote:
>
>> UIWebView iOS 8 scores 440/555 points on html5test.com, and yes it
>> supports indexedDB
>> Full results: http://html5te.st/f16d892273bbe5bd
>>
>> On Tue, Sep 9, 2014 at 1:33 PM, Andrew Grieve <agrieve@chromium.org>
>> wrote:
>>
>>> :(
>>>
>>> Hopefully UIWebView will still get some updates though? E.g. IndexedDb?
>>>
>>> On Tue, Sep 9, 2014 at 4:18 PM, Tommy Williams <tommy@devgeeks.org>
>>> wrote:
>>> > That's pretty disappointing.
>>> >
>>> > Especially with not even a comment from apple.
>>> > On 10 Sep 2014 05:50, "Shazron" <shazron@gmail.com> wrote:
>>> >
>>> >> Well, bad news. I just installed the iOS 8 GM firmware on an iPhone 5
>>> and
>>> >> used Xcode 6 GM, and the file:// url "bug" (assuming it is a bug and
>>> not by
>>> >> design) is still there.
>>> >>
>>> >> http://www.openradar.me/radar?id=5839348817723392
>>> >>
>>> >> On Fri, Sep 5, 2014 at 12:48 PM, Shazron <shazron@gmail.com> wrote:
>>> >>
>>> >> > Clarification:
>>> >> > When I said "The bridge works great, and plugins work great." this
>>> was
>>> >> > for loading a html page and plugins using the file:// protocol using
>>> >> > WKWebView (as the title of the report implies). The bug I reported
>>> was on
>>> >> > Device (> iOS beta 4), on Simulator it is *fine* (this info was in
>>> the
>>> >> bug
>>> >> > report as well).
>>> >> >
>>> >> > *Nothing* has been done using the local web server and proxy (at
>>> least
>>> >> > nothing checked in). An implementation on how the proxy works can be
>>> seen
>>> >> > in the PhoneGap Developer App:
>>> >> > https://github.com/phonegap/phonegap-app-developer
>>> >> >
>>> >> > See CB-7043 for progress on tasks regarding this.
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Fri, Sep 5, 2014 at 11:40 AM, Shazron <shazron@gmail.com> wrote:
>>> >> >
>>> >> >> I figure I will write this all up before the official release of
>>> iOS 8
>>> >> >> next week (probability high) and everyone asking about support.
>>> >> >>
>>> >> >> It has stalled because the WKWebView cannot load files using the
>>> file://
>>> >> >> protocol since iOS 8 beta 4.
>>> >> >>
>>> >> >> This bug has been filed with Apple weeks ago:
>>> >> >> http://www.openradar.me/radar?id=5839348817723392
>>> >> >>
>>> >> >> I even checked WebKit check-ins if there was any progress, so far,
>>> no:
>>> >> >>
>>> >> >>
>>> >>
>>> http://trac.webkit.org/browser/trunk/Source/WebKit2/UIProcess/API/Cocoa?order=date&desc=1
>>> >> >> (but it's entirely possible the loading code is in another part of
>>> the
>>> >> >> tree).
>>> >> >>
>>> >> >> The alternative is to run a local web server, which works great.
>>> >> However,
>>> >> >> this will open up a can of worms possibly with Apple, I'm not sure.
>>> >> >>
>>> >> >> The other interesting tidbit is, with WKWebView, for locally loaded
>>> >> files
>>> >> >> using the file:// protocol, cross-domain restrictions now apply,
>>> unlike
>>> >> >> UIWebView's behaviour. To have the same behaviour as UIWebView, we
>>> would
>>> >> >> need to proxy these requests (modify xhr.open to go to our proxy,
>>> which
>>> >> >> requires the local web server).
>>> >> >>
>>> >> >> The bridge works great, and plugins work great.
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >
>>> >>
>>>
>>
>>