cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: [iOS 8] Status of WKWebView work
Date Wed, 08 Oct 2014 19:27:06 GMT
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 <shazron@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 <shazron@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 <shazron@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 <shazron@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 <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.
>>>> > >>
>>>> > >> 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.
>>>> > >>
>>>> >
>>>>
>>>
>>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message