Clarification: When I said "The bridge works great, and plugins work great." this was for loading a html page and plugins using the file:// protocol using WKWebView (as the title of the report implies). The bug I reported was on Device (> iOS beta 4), on Simulator it is *fine* (this info was in the bug report as well).
*Nothing* has been done using the local web server and proxy (at least nothing checked in). An implementation on how the proxy works can be seen in the PhoneGap Developer App: https://github.com/phonegap/phonegap-app-developer See CB-7043 for progress on tasks regarding this. On Fri, Sep 5, 2014 at 11:40 AM, Shazron <shaz...@gmail.com> wrote: > I figure I will write this all up before the official release of iOS 8 > next week (probability high) and everyone asking about support. > > It has stalled because the WKWebView cannot load files using the file:// > protocol since iOS 8 beta 4. > > This bug has been filed with Apple weeks ago: > http://www.openradar.me/radar?id=5839348817723392 > > I even checked WebKit check-ins if there was any progress, so far, no: > > http://trac.webkit.org/browser/trunk/Source/WebKit2/UIProcess/API/Cocoa?order=date&desc=1 > (but it's entirely possible the loading code is in another part of the > tree). > > The alternative is to run a local web server, which works great. However, > this will open up a can of worms possibly with Apple, I'm not sure. > > The other interesting tidbit is, with WKWebView, for locally loaded files > using the file:// protocol, cross-domain restrictions now apply, unlike > UIWebView's behaviour. To have the same behaviour as UIWebView, we would > need to proxy these requests (modify xhr.open to go to our proxy, which > requires the local web server). > > The bridge works great, and plugins work great. > > > > >
