cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: [iOS 8] WKWebView moving forward
Date Tue, 18 Nov 2014 08:05:20 GMT
Filed https://issues.apache.org/jira/browse/CB-8032 with pull request
included.

On Mon, Nov 17, 2014 at 2:47 PM, Shazron <shazron@gmail.com> wrote:

> Sorry I should have looked into the File API code first (no JavaScript
> changes, that would not work).
>
> Essentially I need to "override" this line from my plugin:
> https://github.com/apache/cordova-plugin-file/blob/82f803ea0d61cde051dcffd27b21dc0ed92a0fdf/src/ios/CDVAssetLibraryFilesystem.m#L74
> (plus the CDVLocalFileSystem equivalent).
>
> Since Obj-C categories can't really "override" methods (behavior
> undefined), and I don't want to do some runtime swap implementation voodoo,
> I would replace the line above with something like:
>
> NSString* nativeURL = [NSString stringWithFormat:@
> "assets-library:/%@",fullPath];
> if ([self respondsToSelector:@selector(nativeFullPath:)]) { // some
> unique selector name perhaps
>      nativeURL = [self nativeFullPath:fullPath]; // this code won't
> compile, pseudo-code for now. Will call my category method defined in my
> plugin for CDVAssetLibraryFileSystem
> }
> dirEntry[@"nativeURL"] = nativeURL;
>
> Backwards compatible.
>
>
> On Mon, Nov 17, 2014 at 1:44 PM, Shazron <shazron@gmail.com> wrote:
>
>> Local Web Server Checklist:
>> 1. We have random port usage
>> 2. We have the token/cookie check
>> 3. We have the localhost check
>> 4. The app is now installed under http://localhost:RANDOM_PORT/www/
>>
>> It'll be easy (relatively) to add  support for:
>> http://localhost:RANDOM_PORT/asset-library/
>> http://localhost:RANDOM_PORT/file-system/
>>
>> The only issue now is changing FileEntry.toURL(). I'm thinking of some
>> runtime 'magic' in the local web server where it detects the File plugin,
>> and change the implementation of FileEntry.toURL() (or through injecting
>> JavaScript, probably easier).
>>
>>
>> On Wed, Oct 29, 2014 at 5:11 PM, Andrew Grieve <agrieve@chromium.org>
>> wrote:
>>
>>> We could restrict access to the webserver by stuffing a cookie into the
>>> webview with an access token, then have the server just 500 on any
>>> request
>>> missing the cookie. We should also be able to restrict external requests
>>> just by listening on 127.0.0.1 instead of 0.0.0.0 (doesn't look
>>> like GCDWebServer supports this, but we can hack it in).
>>>
>>> The problem of port conflicts is annoying though. Maybe we try random
>>> ports
>>> until one works? Is there any need to use the same port for multiple
>>> runs?
>>>
>>> The CORS thing is sad, because it also means things like Camera plugin
>>> will
>>> be broken (can't use resulting URL in <img>).
>>>
>>> Although we might just do (this is different than the current mapping in
>>> the plugin):
>>> http://localhost:RANDOM_PORT/www
>>> http://localhost:RANDOM_PORT/asset-library
>>> http://localhost:RANDOM_PORT/file-system
>>>
>>> to proxy the three locations.
>>>
>>> This also means we can't use FileEntry.toURL() and have it work, unless
>>> toURL returns http://localhost:RANDOM_PORT/file-system/...   Maybe
>>> that's
>>> fine?
>>>
>>>
>>> I don't think it's weird that an app will need to support WKWebView on
>>> some
>>> OS versions, and UIWebView on others. That's already the case to support
>>> iOS 7.
>>>
>>>
>>>
>>> On Wed, Oct 29, 2014 at 6:22 PM, Shazron <shazron@gmail.com> wrote:
>>>
>>> > This does not preclude using the file url API function I suppose.
>>> Here's a
>>> > flowchart on how I think it would work: http://i.imgur.com/zq4zreN.png
>>> >
>>> >
>>> > On Wed, Oct 29, 2014 at 2:48 PM, Tommy Williams <tommy@devgeeks.org>
>>> > wrote:
>>> >
>>> > > This whole thing reeks of sadness and pain.
>>> > >
>>> > > The security implications of this will have to be considered very
>>> > > carefully.
>>> > > On 29 Oct 2014 16:40, "Shazron" <shazron@apache.org> wrote:
>>> > >
>>> > > > ## What We Know So Far
>>> > > >
>>> > > > 1. Because of the file:// url loading bug, we couldn't support
the
>>> > > > WKWebView in the iOS 8 GM release. It has since been fixed, for
>>> release
>>> > > > post iOS 8.1 (not sure when), through a new WKWebView API function
>>> (
>>> > > > http://trac.webkit.org/changeset/174029/trunk)
>>> > > > 2. The alternative is embedding a local web server and serving
>>> assets
>>> > > from
>>> > > > that
>>> > > >
>>> > > > ## Abandon file:// url Loading API Method
>>> > > >
>>> > > > My proposal is, we abandon the local file:// url loading method
in
>>> (1)
>>> > > > above, since it will create problems with support.
>>> > > >
>>> > > > For example, if we support the new local file url loading API
>>> function
>>> > in
>>> > > > iOS 8.2.0 (speculated) -- and a user is on 8.0.2, what then? You
>>> would
>>> > > not
>>> > > > have WKWebView support for that user, and you would use UIWebView
>>> > > instead.
>>> > > > This will just be confusing, and leads to problems.
>>> > > >
>>> > > > With the embedded local web server method, you can support **any**
>>> > > version
>>> > > > of iOS 8.x.
>>> > > >
>>> > > > ## Embrace Embedded Local Web Server Method
>>> > > >
>>> > > > I have a Cordova plugin that implements this, and it should work
>>> with
>>> > > > cordova-ios 3.7.0:
>>> > > > https://github.com/shazron/CordovaLocalWebServer
>>> > > >
>>> > > > It dynamically updates the <access> tag value when it loads,
>>> overriding
>>> > > it
>>> > > > to the actual location and port. Since it is a plugin, it can
be
>>> > > swappable
>>> > > > (for whatever reason).
>>> > > >
>>> > > > It does not solve the problem where any backgrounded app can
>>> access our
>>> > > > local web server.
>>> > > >
>>> > > > ## Future Steps
>>> > > >
>>> > > > This plugin is already working in cordova-ios 3.7.0 (un-released,
>>> up
>>> > next
>>> > > > for vote release).
>>> > > >
>>> > > > The wkwebview branch:
>>> > > >
>>> > > > 1. Needs be rebased
>>> > > > 2. Needs to be re-tested
>>> > > > 3. issues in CB-7043 that relate to the wkwebview have to be
>>> resolved
>>> > > > 4. branch presented for review to other committers
>>> > > > 5. resolve any comments and issues from (4)
>>> > > > 6. wkwebview branch integrated into master
>>> > > >
>>> > > > I will work on these items next after getting cordova-ios 3.7.0
>>> out.
>>> > Any
>>> > > > help is welcome.
>>> > > >
>>> > > > ## Migration Issues
>>> > > >
>>> > > > If you are migrating to WKWebView from UIWebView, you will lose
>>> some
>>> > > > functionality.
>>> > > >
>>> > > > 1. No more whitelist feature (NSURLProtocol is not supported in
>>> > > WKWebView)
>>> > > > 2. Your XmlHttpRequest calls now need to be CORS compliant (this
is
>>> > still
>>> > > > true if loaded through a file:// url)
>>> > > > 3. HTML5 offline application cache is not available in WKWebView
(
>>> > > > https://devforums.apple.com/message/1060452)
>>> > > >
>>> > >
>>> >
>>>
>>
>>
>

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