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 Wed, 10 Dec 2014 23:18:00 GMT
No dice in iOS 8.2b2 that was released today:
https://issues.apache.org/jira/browse/CB-7090?focusedCommentId=14241546&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14241546

On Thu, Nov 20, 2014 at 1:37 PM, Shazron <shazron@gmail.com> wrote:
> I updated https://issues.apache.org/jira/browse/CB-8032 with my revised
> approach. I'd like to move on with this as soon as possible.
>
> Let's continue the discussion there.
>
> On Wed, Nov 19, 2014 at 1:14 PM, Homer, Tony <tony.homer@intel.com> wrote:
>>
>> Ugh.  Thanks for the additional information, Shazron.
>>
>> I had previously proposed adding a hook (by which I meant a delegate
>> method) to CDVPluginResult (that would be called from -
>> (CDVPluginResult*)initWithStatus:(CDVCommandStatus)statusOrdinal
>> message:(id)theMessage) so that LocalWebServer could (blindly) detect and
>> transform urls.
>>
>> It seems like it would help with this case, but not be generally useful
>> for anything else…
>>
>> Tony
>>
>> On 11/19/14, 3:23 PM, "Shazron" <shazron@gmail.com> wrote:
>>
>> >Ideally a general solution like you proposed should work, but I forgot to
>> >mention that in this case, since we are talking about WKWebView, we can't
>> >use NSURLProtocol since it is not supported in that framework [1][2]
>> >
>> >The only other general way I can see is to require explicit support in
>> >plugins, they may have to call something in the
>> >commandDelegate/viewController to transform a url, that can be set by
>> >another plugin, in this case LocalWebServer (my revised proposal was a
>> >'push' this is a 'pull').
>> >
>> >
>> >[1] https://issues.apache.org/jira/browse/CB-7049
>> >[2] http://www.openradar.me/18492325
>> >
>> >On Wed, Nov 19, 2014 at 12:00 PM, Homer, Tony <tony.homer@intel.com>
>> >wrote:
>> >
>> >> 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&p
>> >>a
>> >>
>>
>> >>> >>>ge=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comm
>> >>>en
>> >> >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
>> >>
>> >>
>>
>

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


Mime
View raw message