Re: [iOS 8] Status of WKWebView work

[Andrew Grieve <ag...@chromium.org>]

On Fri, Sep 5, 2014 at 2:40 PM, Shazron <sh...@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.
>

Shaz, did you implement a prototype with a local web server? Would be
useful to see how the code for this works.



>
> 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.
>

Re: [iOS 8] Status of WKWebView work

[Shazron <sh...@gmail.com>]

Ok, I completed the plugin.

cordova plugin add https://github.com/shazron/CordovaLocalWebServer.git

.. then follow the instructions printed after it installs.

Repo: https://github.com/shazron/CordovaLocalWebServer

File issues: https://github.com/shazron/CordovaLocalWebServer/issues


On Wed, Oct 8, 2014 at 12:35 PM, Brian LeRoux <b...@brian.io> wrote:

> Will def be a fun alpha…fwiw I think this is The Future™ for the
> architecture. Opens lots of doors for interop and reuse. Between apps.
> Between devices. Also clears up the network security policy whitelist gong
> show.
>
> On Wed, Oct 8, 2014 at 12:31 PM, Joe Bowser <bo...@gmail.com> wrote:
>
>> How can you guarantee that the port will be released when it goes in the
>> background and not still be bound? That sounds like a main point of
>> failure.  Would you have it increment to the next port if the port is
>> bound?
>>
>> On Wed, Oct 8, 2014 at 12:27 PM, Brian LeRoux <b...@brian.io> wrote:
>>
>>> I guess if it isn't running in the background then a collision is
>>> effectively impossible anyhow.
>>>
>>> On Wed, Oct 8, 2014 at 11:53 AM, Shazron <sh...@gmail.com> wrote:
>>>
>>> > But for 2, there is a chance of port collision still of course,
>>> nothing we
>>> > can do about that. The ideal way is to get a random port, but this
>>> requires
>>> > more Cordova integration which I am trying to avoid (since we need to
>>> > specify the URL in the content tag, we need to know the port as well)
>>> >
>>> > On Wed, Oct 8, 2014 at 11:51 AM, Shazron <sh...@gmail.com> wrote:
>>> >
>>> >> 1. Does it run in the background? No. Unless we put up some variables
>>> in
>>> >> Info.plist, which are reserved for certain types of apps (navigation
>>> apps,
>>> >> etc)
>>> >> 2. Local web server port collision? This will be specified in the
>>> plugin
>>> >> in a preference.
>>> >>
>>> >> On Wed, Oct 8, 2014 at 11:46 AM, Brian LeRoux <b...@brian.io> wrote:
>>> >>
>>> >>> I have some questions! What happens when you background / does it
>>> keep
>>> >>> running? Since you're running localhost, how do you deal with >1 app
>>> >>> (random port collision possible?)
>>> >>>
>>> >>> On Wed, Oct 8, 2014 at 10:33 AM, Shazron <sh...@gmail.com> wrote:
>>> >>>
>>> >>>> Not sure if it's only bound to local requests from localhost. Since
>>> it's
>>> >>>> for experimental reasons, I'm not too concerned for security. I'm
>>> still
>>> >>>> opting for the WKWebView loadFileURL way as the option we use for
>>> our
>>> >>>> users, once that is out.
>>> >>>>
>>> >>>> On Wed, Oct 8, 2014 at 10:31 AM, purplecabbage <
>>> purplecabbage@gmail.com
>>> >>>> >
>>> >>>> wrote:
>>> >>>>
>>> >>>> > What about other requests from the network? Is the server
>>> accessible
>>> >>>> to
>>> >>>> > network peers?
>>> >>>> >
>>> >>>> > Sent from my iPhone
>>> >>>> >
>>> >>>> > > On Oct 8, 2014, at 10:26 AM, Shazron <sh...@gmail.com> wrote:
>>> >>>> > >
>>> >>>> > > I'll release the local webserver soon as a plugin, it was just a
>>> >>>> proof of
>>> >>>> > > concept. It should work with existing Cordova versions as well,
>>> but
>>> >>>> will
>>> >>>> > > not have a way to secure access to the local web server from
>>> other
>>> >>>> > > (background) running apps.
>>> >>>> > >
>>> >>>> > >> On Wed, Oct 8, 2014 at 4:10 AM, Andrew Grieve <
>>> >>>> agrieve@chromium.org>
>>> >>>> > wrote:
>>> >>>> > >>
>>> >>>> > >>> On Fri, Sep 5, 2014 at 2:40 PM, Shazron <sh...@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.
>>> >>>> > >>
>>> >>>> > >> Shaz, did you implement a prototype with a local web server?
>>> Would
>>> >>>> be
>>> >>>> > >> useful to see how the code for this works.
>>> >>>> > >>
>>> >>>> > >>
>>> >>>> > >>
>>> >>>> > >>>
>>> >>>> > >>> 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.
>>> >>>> > >>
>>> >>>> >
>>> >>>>
>>> >>>
>>> >>>
>>> >>
>>> >
>>>
>>
>>
>

Re: [iOS 8] Status of WKWebView work

[Brian LeRoux <b...@brian.io>]

Will def be a fun alpha…fwiw I think this is The Future™ for the
architecture. Opens lots of doors for interop and reuse. Between apps.
Between devices. Also clears up the network security policy whitelist gong
show.

On Wed, Oct 8, 2014 at 12:31 PM, Joe Bowser <bo...@gmail.com> wrote:

> How can you guarantee that the port will be released when it goes in the
> background and not still be bound? That sounds like a main point of
> failure.  Would you have it increment to the next port if the port is
> bound?
>
> On Wed, Oct 8, 2014 at 12:27 PM, Brian LeRoux <b...@brian.io> wrote:
>
>> I guess if it isn't running in the background then a collision is
>> effectively impossible anyhow.
>>
>> On Wed, Oct 8, 2014 at 11:53 AM, Shazron <sh...@gmail.com> wrote:
>>
>> > But for 2, there is a chance of port collision still of course, nothing
>> we
>> > can do about that. The ideal way is to get a random port, but this
>> requires
>> > more Cordova integration which I am trying to avoid (since we need to
>> > specify the URL in the content tag, we need to know the port as well)
>> >
>> > On Wed, Oct 8, 2014 at 11:51 AM, Shazron <sh...@gmail.com> wrote:
>> >
>> >> 1. Does it run in the background? No. Unless we put up some variables
>> in
>> >> Info.plist, which are reserved for certain types of apps (navigation
>> apps,
>> >> etc)
>> >> 2. Local web server port collision? This will be specified in the
>> plugin
>> >> in a preference.
>> >>
>> >> On Wed, Oct 8, 2014 at 11:46 AM, Brian LeRoux <b...@brian.io> wrote:
>> >>
>> >>> I have some questions! What happens when you background / does it keep
>> >>> running? Since you're running localhost, how do you deal with >1 app
>> >>> (random port collision possible?)
>> >>>
>> >>> On Wed, Oct 8, 2014 at 10:33 AM, Shazron <sh...@gmail.com> wrote:
>> >>>
>> >>>> Not sure if it's only bound to local requests from localhost. Since
>> it's
>> >>>> for experimental reasons, I'm not too concerned for security. I'm
>> still
>> >>>> opting for the WKWebView loadFileURL way as the option we use for our
>> >>>> users, once that is out.
>> >>>>
>> >>>> On Wed, Oct 8, 2014 at 10:31 AM, purplecabbage <
>> purplecabbage@gmail.com
>> >>>> >
>> >>>> wrote:
>> >>>>
>> >>>> > What about other requests from the network? Is the server
>> accessible
>> >>>> to
>> >>>> > network peers?
>> >>>> >
>> >>>> > Sent from my iPhone
>> >>>> >
>> >>>> > > On Oct 8, 2014, at 10:26 AM, Shazron <sh...@gmail.com> wrote:
>> >>>> > >
>> >>>> > > I'll release the local webserver soon as a plugin, it was just a
>> >>>> proof of
>> >>>> > > concept. It should work with existing Cordova versions as well,
>> but
>> >>>> will
>> >>>> > > not have a way to secure access to the local web server from
>> other
>> >>>> > > (background) running apps.
>> >>>> > >
>> >>>> > >> On Wed, Oct 8, 2014 at 4:10 AM, Andrew Grieve <
>> >>>> agrieve@chromium.org>
>> >>>> > wrote:
>> >>>> > >>
>> >>>> > >>> On Fri, Sep 5, 2014 at 2:40 PM, Shazron <sh...@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.
>> >>>> > >>
>> >>>> > >> Shaz, did you implement a prototype with a local web server?
>> Would
>> >>>> be
>> >>>> > >> useful to see how the code for this works.
>> >>>> > >>
>> >>>> > >>
>> >>>> > >>
>> >>>> > >>>
>> >>>> > >>> 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.
>> >>>> > >>
>> >>>> >
>> >>>>
>> >>>
>> >>>
>> >>
>> >
>>
>
>

Re: [iOS 8] Status of WKWebView work

[Joe Bowser <bo...@gmail.com>]

How can you guarantee that the port will be released when it goes in the
background and not still be bound? That sounds like a main point of
failure.  Would you have it increment to the next port if the port is
bound?

On Wed, Oct 8, 2014 at 12:27 PM, Brian LeRoux <b...@brian.io> wrote:

> I guess if it isn't running in the background then a collision is
> effectively impossible anyhow.
>
> On Wed, Oct 8, 2014 at 11:53 AM, Shazron <sh...@gmail.com> wrote:
>
> > But for 2, there is a chance of port collision still of course, nothing
> we
> > can do about that. The ideal way is to get a random port, but this
> requires
> > more Cordova integration which I am trying to avoid (since we need to
> > specify the URL in the content tag, we need to know the port as well)
> >
> > On Wed, Oct 8, 2014 at 11:51 AM, Shazron <sh...@gmail.com> wrote:
> >
> >> 1. Does it run in the background? No. Unless we put up some variables in
> >> Info.plist, which are reserved for certain types of apps (navigation
> apps,
> >> etc)
> >> 2. Local web server port collision? This will be specified in the plugin
> >> in a preference.
> >>
> >> On Wed, Oct 8, 2014 at 11:46 AM, Brian LeRoux <b...@brian.io> wrote:
> >>
> >>> I have some questions! What happens when you background / does it keep
> >>> running? Since you're running localhost, how do you deal with >1 app
> >>> (random port collision possible?)
> >>>
> >>> On Wed, Oct 8, 2014 at 10:33 AM, Shazron <sh...@gmail.com> wrote:
> >>>
> >>>> Not sure if it's only bound to local requests from localhost. Since
> it's
> >>>> for experimental reasons, I'm not too concerned for security. I'm
> still
> >>>> opting for the WKWebView loadFileURL way as the option we use for our
> >>>> users, once that is out.
> >>>>
> >>>> On Wed, Oct 8, 2014 at 10:31 AM, purplecabbage <
> purplecabbage@gmail.com
> >>>> >
> >>>> wrote:
> >>>>
> >>>> > What about other requests from the network? Is the server accessible
> >>>> to
> >>>> > network peers?
> >>>> >
> >>>> > Sent from my iPhone
> >>>> >
> >>>> > > On Oct 8, 2014, at 10:26 AM, Shazron <sh...@gmail.com> wrote:
> >>>> > >
> >>>> > > I'll release the local webserver soon as a plugin, it was just a
> >>>> proof of
> >>>> > > concept. It should work with existing Cordova versions as well,
> but
> >>>> will
> >>>> > > not have a way to secure access to the local web server from other
> >>>> > > (background) running apps.
> >>>> > >
> >>>> > >> On Wed, Oct 8, 2014 at 4:10 AM, Andrew Grieve <
> >>>> agrieve@chromium.org>
> >>>> > wrote:
> >>>> > >>
> >>>> > >>> On Fri, Sep 5, 2014 at 2:40 PM, Shazron <sh...@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.
> >>>> > >>
> >>>> > >> Shaz, did you implement a prototype with a local web server?
> Would
> >>>> be
> >>>> > >> useful to see how the code for this works.
> >>>> > >>
> >>>> > >>
> >>>> > >>
> >>>> > >>>
> >>>> > >>> 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.
> >>>> > >>
> >>>> >
> >>>>
> >>>
> >>>
> >>
> >
>

Re: [iOS 8] Status of WKWebView work

[Shazron <sh...@gmail.com>]

Brian:
The chances are small, but a backgrounded app could access the local web
server of the foregrounded Cordova app. If it knew the port (which it may,
through humans inspecting the config.xml in the .app beforehand)

Joe:
Don't have answers to all of those yet, haven't tested that specifically.
I'll release the plugin (soon), test, and let others test as well.

On Wed, Oct 8, 2014 at 12:27 PM, Brian LeRoux <b...@brian.io> wrote:

> I guess if it isn't running in the background then a collision is
> effectively impossible anyhow.
>
> On Wed, Oct 8, 2014 at 11:53 AM, Shazron <sh...@gmail.com> wrote:
>
>> But for 2, there is a chance of port collision still of course, nothing
>> we can do about that. The ideal way is to get a random port, but this
>> requires more Cordova integration which I am trying to avoid (since we need
>> to specify the URL in the content tag, we need to know the port as well)
>>
>> On Wed, Oct 8, 2014 at 11:51 AM, Shazron <sh...@gmail.com> wrote:
>>
>>> 1. Does it run in the background? No. Unless we put up some variables in
>>> Info.plist, which are reserved for certain types of apps (navigation apps,
>>> etc)
>>> 2. Local web server port collision? This will be specified in the plugin
>>> in a preference.
>>>
>>> On Wed, Oct 8, 2014 at 11:46 AM, Brian LeRoux <b...@brian.io> wrote:
>>>
>>>> I have some questions! What happens when you background / does it keep
>>>> running? Since you're running localhost, how do you deal with >1 app
>>>> (random port collision possible?)
>>>>
>>>> On Wed, Oct 8, 2014 at 10:33 AM, Shazron <sh...@gmail.com> wrote:
>>>>
>>>>> Not sure if it's only bound to local requests from localhost. Since
>>>>> it's
>>>>> for experimental reasons, I'm not too concerned for security. I'm still
>>>>> opting for the WKWebView loadFileURL way as the option we use for our
>>>>> users, once that is out.
>>>>>
>>>>> On Wed, Oct 8, 2014 at 10:31 AM, purplecabbage <
>>>>> purplecabbage@gmail.com>
>>>>> wrote:
>>>>>
>>>>> > What about other requests from the network? Is the server accessible
>>>>> to
>>>>> > network peers?
>>>>> >
>>>>> > Sent from my iPhone
>>>>> >
>>>>> > > On Oct 8, 2014, at 10:26 AM, Shazron <sh...@gmail.com> wrote:
>>>>> > >
>>>>> > > I'll release the local webserver soon as a plugin, it was just a
>>>>> proof of
>>>>> > > concept. It should work with existing Cordova versions as well,
>>>>> but will
>>>>> > > not have a way to secure access to the local web server from other
>>>>> > > (background) running apps.
>>>>> > >
>>>>> > >> On Wed, Oct 8, 2014 at 4:10 AM, Andrew Grieve <
>>>>> agrieve@chromium.org>
>>>>> > wrote:
>>>>> > >>
>>>>> > >>> On Fri, Sep 5, 2014 at 2:40 PM, Shazron <sh...@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.
>>>>> > >>
>>>>> > >> Shaz, did you implement a prototype with a local web server?
>>>>> Would be
>>>>> > >> useful to see how the code for this works.
>>>>> > >>
>>>>> > >>
>>>>> > >>
>>>>> > >>>
>>>>> > >>> 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.
>>>>> > >>
>>>>> >
>>>>>
>>>>
>>>>
>>>
>>
>

Re: [iOS 8] Status of WKWebView work

[Brian LeRoux <b...@brian.io>]

I guess if it isn't running in the background then a collision is
effectively impossible anyhow.

On Wed, Oct 8, 2014 at 11:53 AM, Shazron <sh...@gmail.com> wrote:

> But for 2, there is a chance of port collision still of course, nothing we
> can do about that. The ideal way is to get a random port, but this requires
> more Cordova integration which I am trying to avoid (since we need to
> specify the URL in the content tag, we need to know the port as well)
>
> On Wed, Oct 8, 2014 at 11:51 AM, Shazron <sh...@gmail.com> wrote:
>
>> 1. Does it run in the background? No. Unless we put up some variables in
>> Info.plist, which are reserved for certain types of apps (navigation apps,
>> etc)
>> 2. Local web server port collision? This will be specified in the plugin
>> in a preference.
>>
>> On Wed, Oct 8, 2014 at 11:46 AM, Brian LeRoux <b...@brian.io> wrote:
>>
>>> I have some questions! What happens when you background / does it keep
>>> running? Since you're running localhost, how do you deal with >1 app
>>> (random port collision possible?)
>>>
>>> On Wed, Oct 8, 2014 at 10:33 AM, Shazron <sh...@gmail.com> wrote:
>>>
>>>> Not sure if it's only bound to local requests from localhost. Since it's
>>>> for experimental reasons, I'm not too concerned for security. I'm still
>>>> opting for the WKWebView loadFileURL way as the option we use for our
>>>> users, once that is out.
>>>>
>>>> On Wed, Oct 8, 2014 at 10:31 AM, purplecabbage <purplecabbage@gmail.com
>>>> >
>>>> wrote:
>>>>
>>>> > What about other requests from the network? Is the server accessible
>>>> to
>>>> > network peers?
>>>> >
>>>> > Sent from my iPhone
>>>> >
>>>> > > On Oct 8, 2014, at 10:26 AM, Shazron <sh...@gmail.com> wrote:
>>>> > >
>>>> > > I'll release the local webserver soon as a plugin, it was just a
>>>> proof of
>>>> > > concept. It should work with existing Cordova versions as well, but
>>>> will
>>>> > > not have a way to secure access to the local web server from other
>>>> > > (background) running apps.
>>>> > >
>>>> > >> On Wed, Oct 8, 2014 at 4:10 AM, Andrew Grieve <
>>>> agrieve@chromium.org>
>>>> > wrote:
>>>> > >>
>>>> > >>> On Fri, Sep 5, 2014 at 2:40 PM, Shazron <sh...@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.
>>>> > >>
>>>> > >> Shaz, did you implement a prototype with a local web server? Would
>>>> be
>>>> > >> useful to see how the code for this works.
>>>> > >>
>>>> > >>
>>>> > >>
>>>> > >>>
>>>> > >>> 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.
>>>> > >>
>>>> >
>>>>
>>>
>>>
>>
>

Re: [iOS 8] Status of WKWebView work

[Shazron <sh...@gmail.com>]

But for 2, there is a chance of port collision still of course, nothing we
can do about that. The ideal way is to get a random port, but this requires
more Cordova integration which I am trying to avoid (since we need to
specify the URL in the content tag, we need to know the port as well)

On Wed, Oct 8, 2014 at 11:51 AM, Shazron <sh...@gmail.com> wrote:

> 1. Does it run in the background? No. Unless we put up some variables in
> Info.plist, which are reserved for certain types of apps (navigation apps,
> etc)
> 2. Local web server port collision? This will be specified in the plugin
> in a preference.
>
> On Wed, Oct 8, 2014 at 11:46 AM, Brian LeRoux <b...@brian.io> wrote:
>
>> I have some questions! What happens when you background / does it keep
>> running? Since you're running localhost, how do you deal with >1 app
>> (random port collision possible?)
>>
>> On Wed, Oct 8, 2014 at 10:33 AM, Shazron <sh...@gmail.com> wrote:
>>
>>> Not sure if it's only bound to local requests from localhost. Since it's
>>> for experimental reasons, I'm not too concerned for security. I'm still
>>> opting for the WKWebView loadFileURL way as the option we use for our
>>> users, once that is out.
>>>
>>> On Wed, Oct 8, 2014 at 10:31 AM, purplecabbage <pu...@gmail.com>
>>> wrote:
>>>
>>> > What about other requests from the network? Is the server accessible to
>>> > network peers?
>>> >
>>> > Sent from my iPhone
>>> >
>>> > > On Oct 8, 2014, at 10:26 AM, Shazron <sh...@gmail.com> wrote:
>>> > >
>>> > > I'll release the local webserver soon as a plugin, it was just a
>>> proof of
>>> > > concept. It should work with existing Cordova versions as well, but
>>> will
>>> > > not have a way to secure access to the local web server from other
>>> > > (background) running apps.
>>> > >
>>> > >> On Wed, Oct 8, 2014 at 4:10 AM, Andrew Grieve <agrieve@chromium.org
>>> >
>>> > wrote:
>>> > >>
>>> > >>> On Fri, Sep 5, 2014 at 2:40 PM, Shazron <sh...@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.
>>> > >>
>>> > >> Shaz, did you implement a prototype with a local web server? Would
>>> be
>>> > >> useful to see how the code for this works.
>>> > >>
>>> > >>
>>> > >>
>>> > >>>
>>> > >>> 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.
>>> > >>
>>> >
>>>
>>
>>
>

Re: [iOS 8] Status of WKWebView work

[Shazron <sh...@gmail.com>]

1. Does it run in the background? No. Unless we put up some variables in
Info.plist, which are reserved for certain types of apps (navigation apps,
etc)
2. Local web server port collision? This will be specified in the plugin in
a preference.

On Wed, Oct 8, 2014 at 11:46 AM, Brian LeRoux <b...@brian.io> wrote:

> I have some questions! What happens when you background / does it keep
> running? Since you're running localhost, how do you deal with >1 app
> (random port collision possible?)
>
> On Wed, Oct 8, 2014 at 10:33 AM, Shazron <sh...@gmail.com> wrote:
>
>> Not sure if it's only bound to local requests from localhost. Since it's
>> for experimental reasons, I'm not too concerned for security. I'm still
>> opting for the WKWebView loadFileURL way as the option we use for our
>> users, once that is out.
>>
>> On Wed, Oct 8, 2014 at 10:31 AM, purplecabbage <pu...@gmail.com>
>> wrote:
>>
>> > What about other requests from the network? Is the server accessible to
>> > network peers?
>> >
>> > Sent from my iPhone
>> >
>> > > On Oct 8, 2014, at 10:26 AM, Shazron <sh...@gmail.com> wrote:
>> > >
>> > > I'll release the local webserver soon as a plugin, it was just a
>> proof of
>> > > concept. It should work with existing Cordova versions as well, but
>> will
>> > > not have a way to secure access to the local web server from other
>> > > (background) running apps.
>> > >
>> > >> On Wed, Oct 8, 2014 at 4:10 AM, Andrew Grieve <ag...@chromium.org>
>> > wrote:
>> > >>
>> > >>> On Fri, Sep 5, 2014 at 2:40 PM, Shazron <sh...@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.
>> > >>
>> > >> Shaz, did you implement a prototype with a local web server? Would be
>> > >> useful to see how the code for this works.
>> > >>
>> > >>
>> > >>
>> > >>>
>> > >>> 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.
>> > >>
>> >
>>
>
>

Re: [iOS 8] Status of WKWebView work

[Brian LeRoux <b...@brian.io>]

I have some questions! What happens when you background / does it keep
running? Since you're running localhost, how do you deal with >1 app
(random port collision possible?)

On Wed, Oct 8, 2014 at 10:33 AM, Shazron <sh...@gmail.com> wrote:

> Not sure if it's only bound to local requests from localhost. Since it's
> for experimental reasons, I'm not too concerned for security. I'm still
> opting for the WKWebView loadFileURL way as the option we use for our
> users, once that is out.
>
> On Wed, Oct 8, 2014 at 10:31 AM, purplecabbage <pu...@gmail.com>
> wrote:
>
> > What about other requests from the network? Is the server accessible to
> > network peers?
> >
> > Sent from my iPhone
> >
> > > On Oct 8, 2014, at 10:26 AM, Shazron <sh...@gmail.com> wrote:
> > >
> > > I'll release the local webserver soon as a plugin, it was just a proof
> of
> > > concept. It should work with existing Cordova versions as well, but
> will
> > > not have a way to secure access to the local web server from other
> > > (background) running apps.
> > >
> > >> On Wed, Oct 8, 2014 at 4:10 AM, Andrew Grieve <ag...@chromium.org>
> > wrote:
> > >>
> > >>> On Fri, Sep 5, 2014 at 2:40 PM, Shazron <sh...@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.
> > >>
> > >> Shaz, did you implement a prototype with a local web server? Would be
> > >> useful to see how the code for this works.
> > >>
> > >>
> > >>
> > >>>
> > >>> 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.
> > >>
> >
>

Re: [iOS 8] Status of WKWebView work

[Marcel Kinard <cm...@gmail.com>]

On Linux, it's pretty easy to listen only on localhost, I don't know how difficult it is here. I would think that even for an experimental plugin, not being accessible to peers is really important. Not being accessible to other local apps will likely become important in the future.

It still scares me that a local http server is the solution, but alas I see how there aren't other options available yet. Crossing fingers for a fix from Apple in iOS 8.1...

On Oct 8, 2014, at 1:33 PM, Shazron <sh...@gmail.com> wrote:

> Not sure if it's only bound to local requests from localhost. Since it's
> for experimental reasons, I'm not too concerned for security. I'm still
> opting for the WKWebView loadFileURL way as the option we use for our
> users, once that is out.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org

Re: [iOS 8] Status of WKWebView work

[Shazron <sh...@gmail.com>]

Not sure if it's only bound to local requests from localhost. Since it's
for experimental reasons, I'm not too concerned for security. I'm still
opting for the WKWebView loadFileURL way as the option we use for our
users, once that is out.

On Wed, Oct 8, 2014 at 10:31 AM, purplecabbage <pu...@gmail.com>
wrote:

> What about other requests from the network? Is the server accessible to
> network peers?
>
> Sent from my iPhone
>
> > On Oct 8, 2014, at 10:26 AM, Shazron <sh...@gmail.com> wrote:
> >
> > I'll release the local webserver soon as a plugin, it was just a proof of
> > concept. It should work with existing Cordova versions as well, but will
> > not have a way to secure access to the local web server from other
> > (background) running apps.
> >
> >> On Wed, Oct 8, 2014 at 4:10 AM, Andrew Grieve <ag...@chromium.org>
> wrote:
> >>
> >>> On Fri, Sep 5, 2014 at 2:40 PM, Shazron <sh...@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.
> >>
> >> Shaz, did you implement a prototype with a local web server? Would be
> >> useful to see how the code for this works.
> >>
> >>
> >>
> >>>
> >>> 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.
> >>
>

Re: [iOS 8] Status of WKWebView work

[purplecabbage <pu...@gmail.com>]

What about other requests from the network? Is the server accessible to network peers?

Sent from my iPhone

> On Oct 8, 2014, at 10:26 AM, Shazron <sh...@gmail.com> wrote:
> 
> I'll release the local webserver soon as a plugin, it was just a proof of
> concept. It should work with existing Cordova versions as well, but will
> not have a way to secure access to the local web server from other
> (background) running apps.
> 
>> On Wed, Oct 8, 2014 at 4:10 AM, Andrew Grieve <ag...@chromium.org> wrote:
>> 
>>> On Fri, Sep 5, 2014 at 2:40 PM, Shazron <sh...@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.
>> 
>> Shaz, did you implement a prototype with a local web server? Would be
>> useful to see how the code for this works.
>> 
>> 
>> 
>>> 
>>> 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.
>> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org

Re: [iOS 8] Status of WKWebView work

[Shazron <sh...@gmail.com>]

I'll release the local webserver soon as a plugin, it was just a proof of
concept. It should work with existing Cordova versions as well, but will
not have a way to secure access to the local web server from other
(background) running apps.

On Wed, Oct 8, 2014 at 4:10 AM, Andrew Grieve <ag...@chromium.org> wrote:

> On Fri, Sep 5, 2014 at 2:40 PM, Shazron <sh...@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.
> >
>
> Shaz, did you implement a prototype with a local web server? Would be
> useful to see how the code for this works.
>
>
>
> >
> > 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.
> >
>

Re: [iOS 8] Status of WKWebView work

["Homer, Tony" <to...@intel.com>]

The Intel XDK Legacy iOS container source is not available, but the local web server is based on CocoaHTTPServer:
https://github.com/robbiehanson/CocoaHTTPServer

It sounded like Shazron already has this working – I was just sharing that, based on my experience, adding a local web server will not be a problem with Apple.
That being said, if any help is needed, I’d be glad to help however I can.

From: Andrew Grieve <ag...@chromium.org>>
Date: Wednesday, October 8, 2014 at 11:43 AM
To: Tony Homer <to...@intel.com>>
Cc: dev <de...@cordova.apache.org>>
Subject: Re: [iOS 8] Status of WKWebView work

Tony - is the code for that available anywhere?

On Wed, Oct 8, 2014 at 7:48 AM, Homer, Tony <to...@intel.com>> wrote:
>
>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.
>

FWIW, the Intel XDK Legacy iOS container runs a local web server that all
content is served from.

Lots of apps have been published - no problem with Apple about this
feature.

On 10/8/14, 7:10 AM, "Andrew Grieve" <ag...@chromium.org>> wrote:

>On Fri, Sep 5, 2014 at 2:40 PM, Shazron <sh...@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?o
>>rder=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.
>>
>
>Shaz, did you implement a prototype with a local web server? Would be
>useful to see how the code for this works.
>
>
>
>>
>> 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.
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org<ma...@cordova.apache.org>
For additional commands, e-mail: dev-help@cordova.apache.org<ma...@cordova.apache.org>



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org

Re: [iOS 8] Status of WKWebView work

[Andrew Grieve <ag...@chromium.org>]

Tony - is the code for that available anywhere?

On Wed, Oct 8, 2014 at 7:48 AM, Homer, Tony <to...@intel.com> wrote:

> >
> >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.
> >
>
> FWIW, the Intel XDK Legacy iOS container runs a local web server that all
> content is served from.
>
> Lots of apps have been published - no problem with Apple about this
> feature.
>
> On 10/8/14, 7:10 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
>
> >On Fri, Sep 5, 2014 at 2:40 PM, Shazron <sh...@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?o
> >>rder=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.
> >>
> >
> >Shaz, did you implement a prototype with a local web server? Would be
> >useful to see how the code for this works.
> >
> >
> >
> >>
> >> 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.
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>

Re: [iOS 8] Status of WKWebView work

["Homer, Tony" <to...@intel.com>]

>
>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.
>

FWIW, the Intel XDK Legacy iOS container runs a local web server that all
content is served from.

Lots of apps have been published - no problem with Apple about this
feature.

On 10/8/14, 7:10 AM, "Andrew Grieve" <ag...@chromium.org> wrote:

>On Fri, Sep 5, 2014 at 2:40 PM, Shazron <sh...@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?o
>>rder=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.
>>
>
>Shaz, did you implement a prototype with a local web server? Would be
>useful to see how the code for this works.
>
>
>
>>
>> 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.
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org