On Thu, Oct 30, 2014 at 5:05 PM, Shazron <shaz...@gmail.com> wrote: > 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 > Awesome! Why even allow a non-random port? Also learned today that in chrome, webcrypto API is disabled for http origins, but enabled for https. Not sure if this is true for Safari as well, but certainly this change will be a can of worms!
> > 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. > Prefixing all resources into a fake top-level directory will eliminate the folder name collision problem I think. > > 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) > > > > > > > > > > > > > > >
