@Brian it's a dark road down that way.. However, the guys at Ludei patched WKWebView and released "WebView+ for iOS" but have not released the source code :( https://github.com/ludei/webview-plus-ios/tree/master/ios/Release-iphoneos
We are playing around over here too, but have limited corp backing right now to do a full port. We may add WebView+ simply as a replacement to UIWebView in our WizViewManager plugin. The WebView+ is installable as a Cordova plugin but you must use the cocoonjs-cli. On Thu, Dec 11, 2014 at 8:47 AM, Brian LeRoux <b...@brian.io> wrote: > so, it appears wkwebview itself is open source [1] …well outside my comfort > zone but feasible we fix these things ourselves? > > [1] > > https://github.com/WebKit/webkit/blob/0190dd5b8c0272beaa705dbc10863a84a3e6af5e/Source/WebKit2/UIProcess/API/Cocoa/WKWebView.h > > > > On Wed, Dec 10, 2014 at 3:18 PM, Shazron <shaz...@gmail.com> wrote: > > > 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 <shaz...@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.ho...@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" <shaz...@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.ho...@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" <shaz...@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 < > > iclell...@chromium.org> > > >> >> >wrote: > > >> >> > > > >> >> >> On Tue Nov 18 2014 at 2:00:34 PM Jesse <purplecabb...@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 > > >> >><agri...@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 < > shaz...@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 < > shaz...@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 < > > shaz...@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 < > > >> >> >> > agri...@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 > > >> >><shaz...@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 < > > >> >> >> > > to...@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" < > shaz...@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-unsubscr...@cordova.apache.org > > >> >> For additional commands, e-mail: dev-h...@cordova.apache.org > > >> >> > > >> >> > > >> > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > -- <http://www.wizcorp.jp/>Ally Ogilvie Lead Developer - MobDev. | Wizcorp Inc. <http://www.wizcorp.jp/> ------------------------------ TECH . GAMING . OPEN-SOURCE WIZARDS+ 81 (0)3-4550-1448 | Website <http://www.wizcorp.jp/> | Twitter <https://twitter.com/Wizcorp> | Facebook <http://www.facebook.com/Wizcorp> | LinkedIn <http://www.linkedin.com/company/wizcorp>
