The port conflict situation has been solved with the latest version of the plugin. Passing in a port of "0" will choose a random port. More details in the plugin's README.md
Ouch - didn't think about Camera plugin and File plugin impact. That proxy thing might work, as long as there are no folder name collisions. My point regarding mixing WKWebView and UIWebView on iOS 8 is, if you have a user on iOS 8.x, you want all users on that iOS version to have the same experience, and for bug reporting purposes. 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) > > > > > > > > > >
