cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Homer, Tony" <tony.ho...@intel.com>
Subject Re: [iOS 8] WKWebView moving forward
Date Wed, 19 Nov 2014 20:00:38 GMT
If we are just talking about CB-8032, then I can see that this approach is
cleaner for the file plugin.

Regarding local web server plugin in general - what about other plugins
such as camera?
Doesn┬╣t there need to be a general solution that will provide
compatibility between local web server plugin and any plugin that returns
a file protocol URL?

Tony

On 11/19/14, 12:19 PM, "Shazron" <shazron@gmail.com> wrote:

>I commented on Ian's comment on CB-8032:
>https://issues.apache.org/jira/browse/CB-8032?focusedCommentId=14216403&pa
>ge=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#commen
>t-14216403
>
>My goal was to have a loose coupling of this functionality (CDVFile need
>not know about LocalWebServer at all) -- and Ian's comment of this change
>is that would impact all CDVFileSystem instances makes this not an ideal
>solution, what if you have two Cordova WebView instances, etc.
>
>My revised proposal requires CDVFileSystem to have a delegate that can be
>set. Any class can set it to override the nativeURL behaviour, and
>CDVFileSystem will call this method in the delegate if available. It
>achieves the same goal without the potentially undefined behaviour of an
>Obj-C Category.
>
>The LocalWebServer gets the currently installed File plugin, enumerates
>all
>available filesystems, and sets this delegate on each, to its own
>implementation.
>
>Tony - I think this is approach is cleaner, and is more maintainable.
>
>On Wed, Nov 19, 2014 at 6:20 AM, Ian Clelland <iclelland@chromium.org>
>wrote:
>
>> On Tue Nov 18 2014 at 2:00:34 PM Jesse <purplecabbage@gmail.com> wrote:
>>
>> > Shaz's solution has less impact and seems more elegant.
>> >
>> > // if ([self respondsToSelector:@selector(nativeFullPath:)]) {
>> >
>> > If no-one ( generically ) has provided the nativeFullPath method, then
>> use
>> > it as is, otherwise call it.
>> > No need for any (direct) dependency between File + LocalServer.
>> >
>>
>> My first instinct, looking at the code, was that it was wrong, exactly
>> because there *is* a dependency. You don't normally add code to a base
>> class to change its behaviour when there is a category defined on it.
>> Normally that goes the other way: when you add a category to a base
>>class,
>> all of the code that's relevant to that category is *in the category*,
>>and
>> the base class needs to know nothing at all about it, including its
>> existence.
>>
>> As I said in the PR, it may be that this really is the cleanest and best
>> way to go forward with this; I just wanted to have this discussion and
>> figure it out with the community before committing to any
>> hard-to-change-later technical debt. It does become an API surface, and
>>we
>> will have to maintain whatever we adopt.
>>
>> Ian
>>
>>
>> >
>> > @purplecabbage
>> > risingj.com
>> >
>> > On Tue, Nov 18, 2014 at 10:42 AM, Andrew Grieve <agrieve@chromium.org>
>> > wrote:
>> >
>> > > Having the localserver plugin add behaviour to file plugin feels
>>like
>> the
>> > > dependency is in the wrong direction to me.
>> > >
>> > > How about having CDVFile.m do something like:
>> > >
>> > > CDVPlugin* p = [commandDelegate getCommandInstance:@"LocalServer"];
>> > > if (p != nil) {
>> > >   nativeURL = [p transformURL:nativeURL]; // do some local
>>declaration
>> to
>> > > make this not complain about unrecognized selector
>> > > }
>> > >
>> > > Would probably also need an "untransformURL" to go the other
>>direction
>> as
>> > > well.
>> > >
>> > > On Tue, Nov 18, 2014 at 12:05 AM, Shazron <shazron@gmail.com> wrote:
>> > >
>> > > > 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)
>> > > > >>> > > >
>> > > > >>> > >
>> > > > >>> >
>> > > > >>>
>> > > > >>
>> > > > >>
>> > > > >
>> > > >
>> > >
>> >
>>


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


Mime
View raw message