Re: [iOS 8] WKWebView moving forward
I would certainly like to see a test to see what the lag is like... -- tommy-carlos williams On 11 June 2015 at 02:01:35, Shazron (shaz...@gmail.com) wrote: Safari View Controller video: https://developer.apple.com/videos/wwdc/2015/?id=504 What's New in Web Development in WebKit and Safari video: https://developer.apple.com/videos/wwdc/2015/?id=501 On Tue, Jun 9, 2015 at 3:59 PM, Shazron wrote: > I definitely will watch. > Just read about ODR > https://developer.apple.com/library/prerelease/ios/documentation/FileManagement/Conceptual/On_Demand_Resources_Guide/Chapters/IntroToODR.html#//apple_ref/doc/uid/TP40015083-CH2-SW1 > > > So we could still use the copy method (fast, small app bundle) and have a > solution in Cordova for ODR for app bundles that are huge. For example, in > the CLI prepare step. > > Of course this won't be a universal solution and is more complicated. > > On Tuesday, June 9, 2015, Carlos Santana wrote: > >> What do we loose, I just attended the session. >> I think for most uses is a win at least in the security aspect >> Watch the session when the video is available and we can discuss later. >> >> On Tue, Jun 9, 2015 at 1:23 PM Shazron wrote: >> >> > We could use it for InAppBrowser but we might lose some features that we >> > have possibly. >> > >> > Anyways, one piece of bad news for WKWebView iOS 9 - you can load file >> urls >> > in Library and Documents, but not the app bundle. >> > https://twitter.com/wkwebview/status/608359163299819521 >> > >> > On Tue, Jun 9, 2015 at 1:02 PM, Carlos Santana >> > wrote: >> > >> > > Yay ! >> > > There is also a new Safari View Controller, don't know if it's >> applicable >> > > to replace wkwebview but at least I think it can be use to build the >> next >> > > gen inappbrowser since its beats a makeup in iOS anyway. >> > > >> > > The session is in 30 minutes so I'm planning attending. >> > > On Mon, Jun 8, 2015 at 2:33 PM Shazron wrote: >> > > >> > > > There is a WWDC session: "Safari Extensibility: Content Blocking and >> > > Shared >> > > > Links". So I'm hopeful for whitelisting >> > > > >> > > > On Mon, Jun 8, 2015 at 1:22 PM, Shazron wrote: >> > > > >> > > > > Moar news https://twitter.com/wkwebview/status/608005652720451584 >> > > > > >> > > > > >> > > > > On Monday, June 8, 2015, Shazron wrote: >> > > > > >> > > > >> Cordova developers rejoice, iOS 9 includes the API to load pages >> > from >> > > > >> file:// urls >> > https://twitter.com/wkwebview/status/608002548151119872 >> > > > >> >> > > > >> On Mon, Feb 9, 2015 at 2:19 PM, Shazron >> wrote: >> > > > >> >> > > > >>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade >> I >> > > > >>> suppose for your dev machines and build servers... >> > > > >>> >> > > > >>> >> > > > >>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams >> > > > >>> wrote: >> > > > >>> > Oh, FFS. >> > > > >>> > >> > > > >>> > I give up on Apple solving this, personally. Most apps don’t >> > > > >>> *actually* need it (they think they do, but they don’t). I am >> going >> > > to >> > > > find >> > > > >>> another way to solve it for our apps… maybe I will actually >> have to >> > > > write a >> > > > >>> native plugin for the crypto :( >> > > > >>> > >> > > > >>> > -- >> > > > >>> > tommy-carlos williams >> > > > >>> > >> > > > >>> > On 10 February 2015 at 08:18:31, Shazron (shaz...@gmail.com) >> > > wrote: >> > > > >>> > >> > > > >>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not* >> > > contain >> > > > >>> > the loadFileURL:readAccessURL: selector that we are all >> waiting >> > for >> > > > >>> > :'( >> > > > >>> > https://twitter.com/wkwebview/status/564865657225756672 >> > > > >>> >> > > > >> >> > > > >> >> > > > >> > > >> > >> >
Re: [iOS 8] WKWebView moving forward
I don't see moving the files to document out from bundle to documents on first lunch as terrible thing. It can be implemented in the mean while. In our downstream district of cordova this is how we handle dynamic app update from server since bundle is read only. But agree best solution is for wkwebview have proper fix. On Thu, Jun 11, 2015 at 12:09 PM Kerri Shotts wrote: > Yeah, I was just about to say that I was pretty sure that sym/hard links > was going to error. > > But that tweet looks promising! I hope that means the fix makes it in time > for Beta 2 so we can play with it. :-) > > > > > On June 11, 2015 at 1:55:58 PM, Shazron (shaz...@gmail.com) wrote: > > I've already tried both sym and hard links. They result in errors, which is > to be expected (if not there's some 'splaining to do) :P > > GOOD news though today! They are fixing the app bundle loadFileURL bug: > https://twitter.com/grorgwork/status/609052546179530752 > > Apparently you can also UI test in WKWebView: > https://twitter.com/joemasilotti/status/60947930429440 > > On Thu, Jun 11, 2015 at 11:26 AM, Andrew Grieve > wrote: > > > Could maybe try creating symlinks / hardlinks to save on space / creation > > time? > > > > On Wed, Jun 10, 2015 at 12:00 PM, Shazron wrote: > > > > > Safari View Controller video: > > > https://developer.apple.com/videos/wwdc/2015/?id=504 > > > > > > What's New in Web Development in WebKit and Safari video: > > > https://developer.apple.com/videos/wwdc/2015/?id=501 > > > > > > > > > On Tue, Jun 9, 2015 at 3:59 PM, Shazron wrote: > > > > > > > I definitely will watch. > > > > Just read about ODR > > > > > > > > > > https://developer.apple.com/library/prerelease/ios/documentation/FileManagement/Conceptual/On_Demand_Resources_Guide/Chapters/IntroToODR.html#//apple_ref/doc/uid/TP40015083-CH2-SW1 > > > > > > > > So we could still use the copy method (fast, small app bundle) and > > have a > > > > solution in Cordova for ODR for app bundles that are huge. For > example, > > > in > > > > the CLI prepare step. > > > > > > > > Of course this won't be a universal solution and is more complicated. > > > > > > > > On Tuesday, June 9, 2015, Carlos Santana > wrote: > > > > > > > >> What do we loose, I just attended the session. > > > >> I think for most uses is a win at least in the security aspect > > > >> Watch the session when the video is available and we can discuss > > later. > > > >> > > > >> On Tue, Jun 9, 2015 at 1:23 PM Shazron wrote: > > > >> > > > >> > We could use it for InAppBrowser but we might lose some features > > that > > > we > > > >> > have possibly. > > > >> > > > > >> > Anyways, one piece of bad news for WKWebView iOS 9 - you can load > > file > > > >> urls > > > >> > in Library and Documents, but not the app bundle. > > > >> > https://twitter.com/wkwebview/status/608359163299819521 > > > >> > > > > >> > On Tue, Jun 9, 2015 at 1:02 PM, Carlos Santana < > > csantan...@gmail.com> > > > >> > wrote: > > > >> > > > > >> > > Yay ! > > > >> > > There is also a new Safari View Controller, don't know if it's > > > >> applicable > > > >> > > to replace wkwebview but at least I think it can be use to build > > the > > > >> next > > > >> > > gen inappbrowser since its beats a makeup in iOS anyway. > > > >> > > > > > >> > > The session is in 30 minutes so I'm planning attending. > > > >> > > On Mon, Jun 8, 2015 at 2:33 PM Shazron > wrote: > > > >> > > > > > >> > > > There is a WWDC session: "Safari Extensibility: Content > Blocking > > > and > > > >> > > Shared > > > >> > > > Links". So I'm hopeful for whitelisting > > > >> > > > > > > >> > > > On Mon, Jun 8, 2015 at 1:22 PM, Shazron > > > wrote: > > > >> > > > > > > >> > > > > Moar news > > > https://twitter.com/wkwebview/status/608005652720451584 > > > >> > > > > > > > >> > > > > > > > >> > > > > On Monday, June 8, 2015, Shazron wrote: > > > >> > > > > > > > >> > > > >> Cordova developers rejoice, iOS 9 includes the API to load > > > pages > > > >> > from > > > >> > > > >> file:// urls > > > >> > https://twitter.com/wkwebview/status/608002548151119872 > > > >> > > > >> > > > >> > > > >> On Mon, Feb 9, 2015 at 2:19 PM, Shazron > > > > >> wrote: > > > >> > > > >> > > > >> > > > >>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to > > > upgrade > > > >> I > > > >> > > > >>> suppose for your dev machines and build servers... > > > >> > > > >>> > > > >> > > > >>> > > > >> > > > >>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams > > > >> > > > >>> wrote: > > > >> > > > >>> > Oh, FFS. > > > >> > > > >>> > > > > >> > > > >>> > I give up on Apple solving this, personally. Most apps > > don’t > > > >> > > > >>> *actually* need it (they think they do, but they don’t). I > > am > > > >> going > > > >> > > to > > > >> > > > find > > > >> > > > >>> another way to solve it for our apps… maybe I will > actually > > > >> have to > > > >> > > > write a > > > >> > > > >>> native plugin for the crypto :( > > > >> > > > >>> > > > > >> > > > >>> > -- > >
Re: [iOS 8] WKWebView moving forward
Yeah, I was just about to say that I was pretty sure that sym/hard links was going to error. But that tweet looks promising! I hope that means the fix makes it in time for Beta 2 so we can play with it. :-) On June 11, 2015 at 1:55:58 PM, Shazron (shaz...@gmail.com) wrote: I've already tried both sym and hard links. They result in errors, which is to be expected (if not there's some 'splaining to do) :P GOOD news though today! They are fixing the app bundle loadFileURL bug: https://twitter.com/grorgwork/status/609052546179530752 Apparently you can also UI test in WKWebView: https://twitter.com/joemasilotti/status/60947930429440 On Thu, Jun 11, 2015 at 11:26 AM, Andrew Grieve wrote: > Could maybe try creating symlinks / hardlinks to save on space / creation > time? > > On Wed, Jun 10, 2015 at 12:00 PM, Shazron wrote: > > > Safari View Controller video: > > https://developer.apple.com/videos/wwdc/2015/?id=504 > > > > What's New in Web Development in WebKit and Safari video: > > https://developer.apple.com/videos/wwdc/2015/?id=501 > > > > > > On Tue, Jun 9, 2015 at 3:59 PM, Shazron wrote: > > > > > I definitely will watch. > > > Just read about ODR > > > > > > https://developer.apple.com/library/prerelease/ios/documentation/FileManagement/Conceptual/On_Demand_Resources_Guide/Chapters/IntroToODR.html#//apple_ref/doc/uid/TP40015083-CH2-SW1 > > > > > > > So we could still use the copy method (fast, small app bundle) and > have a > > > solution in Cordova for ODR for app bundles that are huge. For example, > > in > > > the CLI prepare step. > > > > > > Of course this won't be a universal solution and is more complicated. > > > > > > On Tuesday, June 9, 2015, Carlos Santana wrote: > > > > > >> What do we loose, I just attended the session. > > >> I think for most uses is a win at least in the security aspect > > >> Watch the session when the video is available and we can discuss > later. > > >> > > >> On Tue, Jun 9, 2015 at 1:23 PM Shazron wrote: > > >> > > >> > We could use it for InAppBrowser but we might lose some features > that > > we > > >> > have possibly. > > >> > > > >> > Anyways, one piece of bad news for WKWebView iOS 9 - you can load > file > > >> urls > > >> > in Library and Documents, but not the app bundle. > > >> > https://twitter.com/wkwebview/status/608359163299819521 > > >> > > > >> > On Tue, Jun 9, 2015 at 1:02 PM, Carlos Santana < > csantan...@gmail.com> > > >> > wrote: > > >> > > > >> > > Yay ! > > >> > > There is also a new Safari View Controller, don't know if it's > > >> applicable > > >> > > to replace wkwebview but at least I think it can be use to build > the > > >> next > > >> > > gen inappbrowser since its beats a makeup in iOS anyway. > > >> > > > > >> > > The session is in 30 minutes so I'm planning attending. > > >> > > On Mon, Jun 8, 2015 at 2:33 PM Shazron wrote: > > >> > > > > >> > > > There is a WWDC session: "Safari Extensibility: Content Blocking > > and > > >> > > Shared > > >> > > > Links". So I'm hopeful for whitelisting > > >> > > > > > >> > > > On Mon, Jun 8, 2015 at 1:22 PM, Shazron > > wrote: > > >> > > > > > >> > > > > Moar news > > https://twitter.com/wkwebview/status/608005652720451584 > > >> > > > > > > >> > > > > > > >> > > > > On Monday, June 8, 2015, Shazron wrote: > > >> > > > > > > >> > > > >> Cordova developers rejoice, iOS 9 includes the API to load > > pages > > >> > from > > >> > > > >> file:// urls > > >> > https://twitter.com/wkwebview/status/608002548151119872 > > >> > > > >> > > >> > > > >> On Mon, Feb 9, 2015 at 2:19 PM, Shazron > > >> wrote: > > >> > > > >> > > >> > > > >>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to > > upgrade > > >> I > > >> > > > >>> suppose for your dev machines and build servers... > > >> > > > >>> > > >> > > > >>> > > >> > > > >>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams > > >> > > > >>> wrote: > > >> > > > >>> > Oh, FFS. > > >> > > > >>> > > > >> > > > >>> > I give up on Apple solving this, personally. Most apps > don’t > > >> > > > >>> *actually* need it (they think they do, but they don’t). I > am > > >> going > > >> > > to > > >> > > > find > > >> > > > >>> another way to solve it for our apps… maybe I will actually > > >> have to > > >> > > > write a > > >> > > > >>> native plugin for the crypto :( > > >> > > > >>> > > > >> > > > >>> > -- > > >> > > > >>> > tommy-carlos williams > > >> > > > >>> > > > >> > > > >>> > On 10 February 2015 at 08:18:31, Shazron ( > shaz...@gmail.com > > ) > > >> > > wrote: > > >> > > > >>> > > > >> > > > >>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does > *not* > > >> > > contain > > >> > > > >>> > the loadFileURL:readAccessURL: selector that we are all > > >> waiting > > >> > f
Re: [iOS 8] WKWebView moving forward
I've already tried both sym and hard links. They result in errors, which is to be expected (if not there's some 'splaining to do) :P GOOD news though today! They are fixing the app bundle loadFileURL bug: https://twitter.com/grorgwork/status/609052546179530752 Apparently you can also UI test in WKWebView: https://twitter.com/joemasilotti/status/60947930429440 On Thu, Jun 11, 2015 at 11:26 AM, Andrew Grieve wrote: > Could maybe try creating symlinks / hardlinks to save on space / creation > time? > > On Wed, Jun 10, 2015 at 12:00 PM, Shazron wrote: > > > Safari View Controller video: > > https://developer.apple.com/videos/wwdc/2015/?id=504 > > > > What's New in Web Development in WebKit and Safari video: > > https://developer.apple.com/videos/wwdc/2015/?id=501 > > > > > > On Tue, Jun 9, 2015 at 3:59 PM, Shazron wrote: > > > > > I definitely will watch. > > > Just read about ODR > > > > > > https://developer.apple.com/library/prerelease/ios/documentation/FileManagement/Conceptual/On_Demand_Resources_Guide/Chapters/IntroToODR.html#//apple_ref/doc/uid/TP40015083-CH2-SW1 > > > > > > So we could still use the copy method (fast, small app bundle) and > have a > > > solution in Cordova for ODR for app bundles that are huge. For example, > > in > > > the CLI prepare step. > > > > > > Of course this won't be a universal solution and is more complicated. > > > > > > On Tuesday, June 9, 2015, Carlos Santana wrote: > > > > > >> What do we loose, I just attended the session. > > >> I think for most uses is a win at least in the security aspect > > >> Watch the session when the video is available and we can discuss > later. > > >> > > >> On Tue, Jun 9, 2015 at 1:23 PM Shazron wrote: > > >> > > >> > We could use it for InAppBrowser but we might lose some features > that > > we > > >> > have possibly. > > >> > > > >> > Anyways, one piece of bad news for WKWebView iOS 9 - you can load > file > > >> urls > > >> > in Library and Documents, but not the app bundle. > > >> > https://twitter.com/wkwebview/status/608359163299819521 > > >> > > > >> > On Tue, Jun 9, 2015 at 1:02 PM, Carlos Santana < > csantan...@gmail.com> > > >> > wrote: > > >> > > > >> > > Yay ! > > >> > > There is also a new Safari View Controller, don't know if it's > > >> applicable > > >> > > to replace wkwebview but at least I think it can be use to build > the > > >> next > > >> > > gen inappbrowser since its beats a makeup in iOS anyway. > > >> > > > > >> > > The session is in 30 minutes so I'm planning attending. > > >> > > On Mon, Jun 8, 2015 at 2:33 PM Shazron wrote: > > >> > > > > >> > > > There is a WWDC session: "Safari Extensibility: Content Blocking > > and > > >> > > Shared > > >> > > > Links". So I'm hopeful for whitelisting > > >> > > > > > >> > > > On Mon, Jun 8, 2015 at 1:22 PM, Shazron > > wrote: > > >> > > > > > >> > > > > Moar news > > https://twitter.com/wkwebview/status/608005652720451584 > > >> > > > > > > >> > > > > > > >> > > > > On Monday, June 8, 2015, Shazron wrote: > > >> > > > > > > >> > > > >> Cordova developers rejoice, iOS 9 includes the API to load > > pages > > >> > from > > >> > > > >> file:// urls > > >> > https://twitter.com/wkwebview/status/608002548151119872 > > >> > > > >> > > >> > > > >> On Mon, Feb 9, 2015 at 2:19 PM, Shazron > > >> wrote: > > >> > > > >> > > >> > > > >>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to > > upgrade > > >> I > > >> > > > >>> suppose for your dev machines and build servers... > > >> > > > >>> > > >> > > > >>> > > >> > > > >>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams > > >> > > > >>> wrote: > > >> > > > >>> > Oh, FFS. > > >> > > > >>> > > > >> > > > >>> > I give up on Apple solving this, personally. Most apps > don’t > > >> > > > >>> *actually* need it (they think they do, but they don’t). I > am > > >> going > > >> > > to > > >> > > > find > > >> > > > >>> another way to solve it for our apps… maybe I will actually > > >> have to > > >> > > > write a > > >> > > > >>> native plugin for the crypto :( > > >> > > > >>> > > > >> > > > >>> > -- > > >> > > > >>> > tommy-carlos williams > > >> > > > >>> > > > >> > > > >>> > On 10 February 2015 at 08:18:31, Shazron ( > shaz...@gmail.com > > ) > > >> > > wrote: > > >> > > > >>> > > > >> > > > >>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does > *not* > > >> > > contain > > >> > > > >>> > the loadFileURL:readAccessURL: selector that we are all > > >> waiting > > >> > for > > >> > > > >>> > :'( > > >> > > > >>> > https://twitter.com/wkwebview/status/564865657225756672 > > >> > > > >>> > > >> > > > >> > > >> > > > >> > > >> > > > > > >> > > > > >> > > > >> > > > > > >
RE: [iOS 8] WKWebView moving forward
Hmmm. Symlinks will break if the code ever touches Windows but they could be safely created as a part of a before_compile hook since that would only ever run on OSX practically speaking. (after_prepare would still fire if you add iOS on Windows - which is something we talked about being a potential issue if platforms are referenced in package.json.) -Chuck -Original Message- From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew Grieve Sent: Thursday, June 11, 2015 11:27 AM To: dev Subject: Re: [iOS 8] WKWebView moving forward Could maybe try creating symlinks / hardlinks to save on space / creation time? On Wed, Jun 10, 2015 at 12:00 PM, Shazron wrote: > Safari View Controller video: > https://developer.apple.com/videos/wwdc/2015/?id=504 > > What's New in Web Development in WebKit and Safari video: > https://developer.apple.com/videos/wwdc/2015/?id=501 > > > On Tue, Jun 9, 2015 at 3:59 PM, Shazron wrote: > > > I definitely will watch. > > Just read about ODR > > > https://developer.apple.com/library/prerelease/ios/documentation/FileM > anagement/Conceptual/On_Demand_Resources_Guide/Chapters/IntroToODR.htm > l#//apple_ref/doc/uid/TP40015083-CH2-SW1 > > > > So we could still use the copy method (fast, small app bundle) and > > have a solution in Cordova for ODR for app bundles that are huge. > > For example, > in > > the CLI prepare step. > > > > Of course this won't be a universal solution and is more complicated. > > > > On Tuesday, June 9, 2015, Carlos Santana wrote: > > > >> What do we loose, I just attended the session. > >> I think for most uses is a win at least in the security aspect > >> Watch the session when the video is available and we can discuss later. > >> > >> On Tue, Jun 9, 2015 at 1:23 PM Shazron wrote: > >> > >> > We could use it for InAppBrowser but we might lose some features > >> > that > we > >> > have possibly. > >> > > >> > Anyways, one piece of bad news for WKWebView iOS 9 - you can load > >> > file > >> urls > >> > in Library and Documents, but not the app bundle. > >> > https://twitter.com/wkwebview/status/608359163299819521 > >> > > >> > On Tue, Jun 9, 2015 at 1:02 PM, Carlos Santana > >> > > >> > wrote: > >> > > >> > > Yay ! > >> > > There is also a new Safari View Controller, don't know if it's > >> applicable > >> > > to replace wkwebview but at least I think it can be use to > >> > > build the > >> next > >> > > gen inappbrowser since its beats a makeup in iOS anyway. > >> > > > >> > > The session is in 30 minutes so I'm planning attending. > >> > > On Mon, Jun 8, 2015 at 2:33 PM Shazron wrote: > >> > > > >> > > > There is a WWDC session: "Safari Extensibility: Content > >> > > > Blocking > and > >> > > Shared > >> > > > Links". So I'm hopeful for whitelisting > >> > > > > >> > > > On Mon, Jun 8, 2015 at 1:22 PM, Shazron > wrote: > >> > > > > >> > > > > Moar news > https://twitter.com/wkwebview/status/608005652720451584 > >> > > > > > >> > > > > > >> > > > > On Monday, June 8, 2015, Shazron wrote: > >> > > > > > >> > > > >> Cordova developers rejoice, iOS 9 includes the API to load > pages > >> > from > >> > > > >> file:// urls > >> > https://twitter.com/wkwebview/status/608002548151119872 > >> > > > >> > >> > > > >> On Mon, Feb 9, 2015 at 2:19 PM, Shazron > >> > > > >> > >> wrote: > >> > > > >> > >> > > > >>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to > upgrade > >> I > >> > > > >>> suppose for your dev machines and build servers... > >> > > > >>> > >> > > > >>> > >> > > > >>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams > >> > > > >>> wrote: > >> > > > >>> > Oh, FFS. > >> > > > >>> > > >> > > > >>> > I give up on Apple solving this, personally. Most apps > >> > > > >>> > don’t > >> > > > >>> *actually* need it (they think they do, but they don’t). > >> > > > >>> I am > >> going > >> > > to > >> > > > find > >> > > > >>> another way to solve it for our apps… maybe I will > >> > > > >>> actually > >> have to > >> > > > write a > >> > > > >>> native plugin for the crypto :( > >> > > > >>> > > >> > > > >>> > -- > >> > > > >>> > tommy-carlos williams > >> > > > >>> > > >> > > > >>> > On 10 February 2015 at 08:18:31, Shazron > >> > > > >>> > (shaz...@gmail.com > ) > >> > > wrote: > >> > > > >>> > > >> > > > >>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does > >> > > > >>> > *not* > >> > > contain > >> > > > >>> > the loadFileURL:readAccessURL: selector that we are all > >> waiting > >> > for > >> > > > >>> > :'( > >> > > > >>> > https://twitter.com/wkwebview/status/564865657225756672 > >> > > > >>> > >> > > > >> > >> > > > >> > >> > > > > >> > > > >> > > >> > > >
Re: [iOS 8] WKWebView moving forward
Could maybe try creating symlinks / hardlinks to save on space / creation time? On Wed, Jun 10, 2015 at 12:00 PM, Shazron wrote: > Safari View Controller video: > https://developer.apple.com/videos/wwdc/2015/?id=504 > > What's New in Web Development in WebKit and Safari video: > https://developer.apple.com/videos/wwdc/2015/?id=501 > > > On Tue, Jun 9, 2015 at 3:59 PM, Shazron wrote: > > > I definitely will watch. > > Just read about ODR > > > https://developer.apple.com/library/prerelease/ios/documentation/FileManagement/Conceptual/On_Demand_Resources_Guide/Chapters/IntroToODR.html#//apple_ref/doc/uid/TP40015083-CH2-SW1 > > > > So we could still use the copy method (fast, small app bundle) and have a > > solution in Cordova for ODR for app bundles that are huge. For example, > in > > the CLI prepare step. > > > > Of course this won't be a universal solution and is more complicated. > > > > On Tuesday, June 9, 2015, Carlos Santana wrote: > > > >> What do we loose, I just attended the session. > >> I think for most uses is a win at least in the security aspect > >> Watch the session when the video is available and we can discuss later. > >> > >> On Tue, Jun 9, 2015 at 1:23 PM Shazron wrote: > >> > >> > We could use it for InAppBrowser but we might lose some features that > we > >> > have possibly. > >> > > >> > Anyways, one piece of bad news for WKWebView iOS 9 - you can load file > >> urls > >> > in Library and Documents, but not the app bundle. > >> > https://twitter.com/wkwebview/status/608359163299819521 > >> > > >> > On Tue, Jun 9, 2015 at 1:02 PM, Carlos Santana > >> > wrote: > >> > > >> > > Yay ! > >> > > There is also a new Safari View Controller, don't know if it's > >> applicable > >> > > to replace wkwebview but at least I think it can be use to build the > >> next > >> > > gen inappbrowser since its beats a makeup in iOS anyway. > >> > > > >> > > The session is in 30 minutes so I'm planning attending. > >> > > On Mon, Jun 8, 2015 at 2:33 PM Shazron wrote: > >> > > > >> > > > There is a WWDC session: "Safari Extensibility: Content Blocking > and > >> > > Shared > >> > > > Links". So I'm hopeful for whitelisting > >> > > > > >> > > > On Mon, Jun 8, 2015 at 1:22 PM, Shazron > wrote: > >> > > > > >> > > > > Moar news > https://twitter.com/wkwebview/status/608005652720451584 > >> > > > > > >> > > > > > >> > > > > On Monday, June 8, 2015, Shazron wrote: > >> > > > > > >> > > > >> Cordova developers rejoice, iOS 9 includes the API to load > pages > >> > from > >> > > > >> file:// urls > >> > https://twitter.com/wkwebview/status/608002548151119872 > >> > > > >> > >> > > > >> On Mon, Feb 9, 2015 at 2:19 PM, Shazron > >> wrote: > >> > > > >> > >> > > > >>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to > upgrade > >> I > >> > > > >>> suppose for your dev machines and build servers... > >> > > > >>> > >> > > > >>> > >> > > > >>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams > >> > > > >>> wrote: > >> > > > >>> > Oh, FFS. > >> > > > >>> > > >> > > > >>> > I give up on Apple solving this, personally. Most apps don’t > >> > > > >>> *actually* need it (they think they do, but they don’t). I am > >> going > >> > > to > >> > > > find > >> > > > >>> another way to solve it for our apps… maybe I will actually > >> have to > >> > > > write a > >> > > > >>> native plugin for the crypto :( > >> > > > >>> > > >> > > > >>> > -- > >> > > > >>> > tommy-carlos williams > >> > > > >>> > > >> > > > >>> > On 10 February 2015 at 08:18:31, Shazron (shaz...@gmail.com > ) > >> > > wrote: > >> > > > >>> > > >> > > > >>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not* > >> > > contain > >> > > > >>> > the loadFileURL:readAccessURL: selector that we are all > >> waiting > >> > for > >> > > > >>> > :'( > >> > > > >>> > https://twitter.com/wkwebview/status/564865657225756672 > >> > > > >>> > >> > > > >> > >> > > > >> > >> > > > > >> > > > >> > > >> > > >
Re: [iOS 8] WKWebView moving forward
Safari View Controller video: https://developer.apple.com/videos/wwdc/2015/?id=504 What's New in Web Development in WebKit and Safari video: https://developer.apple.com/videos/wwdc/2015/?id=501 On Tue, Jun 9, 2015 at 3:59 PM, Shazron wrote: > I definitely will watch. > Just read about ODR > https://developer.apple.com/library/prerelease/ios/documentation/FileManagement/Conceptual/On_Demand_Resources_Guide/Chapters/IntroToODR.html#//apple_ref/doc/uid/TP40015083-CH2-SW1 > > So we could still use the copy method (fast, small app bundle) and have a > solution in Cordova for ODR for app bundles that are huge. For example, in > the CLI prepare step. > > Of course this won't be a universal solution and is more complicated. > > On Tuesday, June 9, 2015, Carlos Santana wrote: > >> What do we loose, I just attended the session. >> I think for most uses is a win at least in the security aspect >> Watch the session when the video is available and we can discuss later. >> >> On Tue, Jun 9, 2015 at 1:23 PM Shazron wrote: >> >> > We could use it for InAppBrowser but we might lose some features that we >> > have possibly. >> > >> > Anyways, one piece of bad news for WKWebView iOS 9 - you can load file >> urls >> > in Library and Documents, but not the app bundle. >> > https://twitter.com/wkwebview/status/608359163299819521 >> > >> > On Tue, Jun 9, 2015 at 1:02 PM, Carlos Santana >> > wrote: >> > >> > > Yay ! >> > > There is also a new Safari View Controller, don't know if it's >> applicable >> > > to replace wkwebview but at least I think it can be use to build the >> next >> > > gen inappbrowser since its beats a makeup in iOS anyway. >> > > >> > > The session is in 30 minutes so I'm planning attending. >> > > On Mon, Jun 8, 2015 at 2:33 PM Shazron wrote: >> > > >> > > > There is a WWDC session: "Safari Extensibility: Content Blocking and >> > > Shared >> > > > Links". So I'm hopeful for whitelisting >> > > > >> > > > On Mon, Jun 8, 2015 at 1:22 PM, Shazron wrote: >> > > > >> > > > > Moar news https://twitter.com/wkwebview/status/608005652720451584 >> > > > > >> > > > > >> > > > > On Monday, June 8, 2015, Shazron wrote: >> > > > > >> > > > >> Cordova developers rejoice, iOS 9 includes the API to load pages >> > from >> > > > >> file:// urls >> > https://twitter.com/wkwebview/status/608002548151119872 >> > > > >> >> > > > >> On Mon, Feb 9, 2015 at 2:19 PM, Shazron >> wrote: >> > > > >> >> > > > >>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade >> I >> > > > >>> suppose for your dev machines and build servers... >> > > > >>> >> > > > >>> >> > > > >>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams >> > > > >>> wrote: >> > > > >>> > Oh, FFS. >> > > > >>> > >> > > > >>> > I give up on Apple solving this, personally. Most apps don’t >> > > > >>> *actually* need it (they think they do, but they don’t). I am >> going >> > > to >> > > > find >> > > > >>> another way to solve it for our apps… maybe I will actually >> have to >> > > > write a >> > > > >>> native plugin for the crypto :( >> > > > >>> > >> > > > >>> > -- >> > > > >>> > tommy-carlos williams >> > > > >>> > >> > > > >>> > On 10 February 2015 at 08:18:31, Shazron (shaz...@gmail.com) >> > > wrote: >> > > > >>> > >> > > > >>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not* >> > > contain >> > > > >>> > the loadFileURL:readAccessURL: selector that we are all >> waiting >> > for >> > > > >>> > :'( >> > > > >>> > https://twitter.com/wkwebview/status/564865657225756672 >> > > > >>> >> > > > >> >> > > > >> >> > > > >> > > >> > >> >
Re: [iOS 8] WKWebView moving forward
I definitely will watch. Just read about ODR https://developer.apple.com/library/prerelease/ios/documentation/FileManagement/Conceptual/On_Demand_Resources_Guide/Chapters/IntroToODR.html#//apple_ref/doc/uid/TP40015083-CH2-SW1 So we could still use the copy method (fast, small app bundle) and have a solution in Cordova for ODR for app bundles that are huge. For example, in the CLI prepare step. Of course this won't be a universal solution and is more complicated. On Tuesday, June 9, 2015, Carlos Santana wrote: > What do we loose, I just attended the session. > I think for most uses is a win at least in the security aspect > Watch the session when the video is available and we can discuss later. > > On Tue, Jun 9, 2015 at 1:23 PM Shazron > > wrote: > > > We could use it for InAppBrowser but we might lose some features that we > > have possibly. > > > > Anyways, one piece of bad news for WKWebView iOS 9 - you can load file > urls > > in Library and Documents, but not the app bundle. > > https://twitter.com/wkwebview/status/608359163299819521 > > > > On Tue, Jun 9, 2015 at 1:02 PM, Carlos Santana > > > wrote: > > > > > Yay ! > > > There is also a new Safari View Controller, don't know if it's > applicable > > > to replace wkwebview but at least I think it can be use to build the > next > > > gen inappbrowser since its beats a makeup in iOS anyway. > > > > > > The session is in 30 minutes so I'm planning attending. > > > On Mon, Jun 8, 2015 at 2:33 PM Shazron > wrote: > > > > > > > There is a WWDC session: "Safari Extensibility: Content Blocking and > > > Shared > > > > Links". So I'm hopeful for whitelisting > > > > > > > > On Mon, Jun 8, 2015 at 1:22 PM, Shazron > wrote: > > > > > > > > > Moar news https://twitter.com/wkwebview/status/608005652720451584 > > > > > > > > > > > > > > > On Monday, June 8, 2015, Shazron > > wrote: > > > > > > > > > >> Cordova developers rejoice, iOS 9 includes the API to load pages > > from > > > > >> file:// urls > > https://twitter.com/wkwebview/status/608002548151119872 > > > > >> > > > > >> On Mon, Feb 9, 2015 at 2:19 PM, Shazron > wrote: > > > > >> > > > > >>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade I > > > > >>> suppose for your dev machines and build servers... > > > > >>> > > > > >>> > > > > >>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams > > > > >>> > wrote: > > > > >>> > Oh, FFS. > > > > >>> > > > > > >>> > I give up on Apple solving this, personally. Most apps don’t > > > > >>> *actually* need it (they think they do, but they don’t). I am > going > > > to > > > > find > > > > >>> another way to solve it for our apps… maybe I will actually have > to > > > > write a > > > > >>> native plugin for the crypto :( > > > > >>> > > > > > >>> > -- > > > > >>> > tommy-carlos williams > > > > >>> > > > > > >>> > On 10 February 2015 at 08:18:31, Shazron (shaz...@gmail.com > ) > > > wrote: > > > > >>> > > > > > >>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not* > > > contain > > > > >>> > the loadFileURL:readAccessURL: selector that we are all waiting > > for > > > > >>> > :'( > > > > >>> > https://twitter.com/wkwebview/status/564865657225756672 > > > > >>> > > > > >> > > > > >> > > > > > > > > > >
Re: [iOS 8] WKWebView moving forward
What do we loose, I just attended the session. I think for most uses is a win at least in the security aspect Watch the session when the video is available and we can discuss later. On Tue, Jun 9, 2015 at 1:23 PM Shazron wrote: > We could use it for InAppBrowser but we might lose some features that we > have possibly. > > Anyways, one piece of bad news for WKWebView iOS 9 - you can load file urls > in Library and Documents, but not the app bundle. > https://twitter.com/wkwebview/status/608359163299819521 > > On Tue, Jun 9, 2015 at 1:02 PM, Carlos Santana > wrote: > > > Yay ! > > There is also a new Safari View Controller, don't know if it's applicable > > to replace wkwebview but at least I think it can be use to build the next > > gen inappbrowser since its beats a makeup in iOS anyway. > > > > The session is in 30 minutes so I'm planning attending. > > On Mon, Jun 8, 2015 at 2:33 PM Shazron wrote: > > > > > There is a WWDC session: "Safari Extensibility: Content Blocking and > > Shared > > > Links". So I'm hopeful for whitelisting > > > > > > On Mon, Jun 8, 2015 at 1:22 PM, Shazron wrote: > > > > > > > Moar news https://twitter.com/wkwebview/status/608005652720451584 > > > > > > > > > > > > On Monday, June 8, 2015, Shazron wrote: > > > > > > > >> Cordova developers rejoice, iOS 9 includes the API to load pages > from > > > >> file:// urls > https://twitter.com/wkwebview/status/608002548151119872 > > > >> > > > >> On Mon, Feb 9, 2015 at 2:19 PM, Shazron wrote: > > > >> > > > >>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade I > > > >>> suppose for your dev machines and build servers... > > > >>> > > > >>> > > > >>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams > > > >>> wrote: > > > >>> > Oh, FFS. > > > >>> > > > > >>> > I give up on Apple solving this, personally. Most apps don’t > > > >>> *actually* need it (they think they do, but they don’t). I am going > > to > > > find > > > >>> another way to solve it for our apps… maybe I will actually have to > > > write a > > > >>> native plugin for the crypto :( > > > >>> > > > > >>> > -- > > > >>> > tommy-carlos williams > > > >>> > > > > >>> > On 10 February 2015 at 08:18:31, Shazron (shaz...@gmail.com) > > wrote: > > > >>> > > > > >>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not* > > contain > > > >>> > the loadFileURL:readAccessURL: selector that we are all waiting > for > > > >>> > :'( > > > >>> > https://twitter.com/wkwebview/status/564865657225756672 > > > >>> > > > >> > > > >> > > > > > >
Re: [iOS 8] WKWebView moving forward
I hadn’t considered the space issue. Mind you, my apps are like 1.7MB. Not exactly space hogs. At least the camera and downloads issues would be fixed :( -- tommy-carlos williams On 10 June 2015 at 07:04:00, Shazron (shaz...@gmail.com) wrote: +1 to what Kerri said. If we did it, it would be in Library/Caches since that is not backed up by iTunes: https://developer.apple.com/library/ios/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html#//apple_ref/doc/uid/TP40010672-CH2-SW1 On Tue, Jun 9, 2015 at 1:58 PM, Kerri Shotts wrote: > Speaking as a user who has an iPhone that’s always running near the > storage limit: I’d hate to see files be duplicate out of the bundle into > another location… my phone might cry. > > I think we went over that when WKWebview was first released. Copying files > was discussed, but it adds an awful lot of complexity to startup, wastes > space, etc. Looks like the local web server might be the best option, still. > > But I guess this gives the option of using web content that the app itself > downloads to /Documents or /Library, so that could be nice. Unfortunate > that they hamstrung it regarding bundles tho. Here’s hoping they’ll change > it, but given the track record in iOS 8, I’m not holding my breath. > > > > > On June 9, 2015 at 3:50:09 PM, Ross Gerbasi (rgerb...@gmail.com) wrote: > > Would it be a horrible idea to copy files into one of those folders? > > On Tue, Jun 9, 2015 at 3:22 PM, Shazron wrote: > > > We could use it for InAppBrowser but we might lose some features that we > > have possibly. > > > > Anyways, one piece of bad news for WKWebView iOS 9 - you can load file > urls > > in Library and Documents, but not the app bundle. > > https://twitter.com/wkwebview/status/608359163299819521 > > > > On Tue, Jun 9, 2015 at 1:02 PM, Carlos Santana > > wrote: > > > > > Yay ! > > > There is also a new Safari View Controller, don't know if it's > applicable > > > to replace wkwebview but at least I think it can be use to build the > next > > > gen inappbrowser since its beats a makeup in iOS anyway. > > > > > > The session is in 30 minutes so I'm planning attending. > > > On Mon, Jun 8, 2015 at 2:33 PM Shazron wrote: > > > > > > > There is a WWDC session: "Safari Extensibility: Content Blocking and > > > Shared > > > > Links". So I'm hopeful for whitelisting > > > > > > > > On Mon, Jun 8, 2015 at 1:22 PM, Shazron wrote: > > > > > > > > > Moar news https://twitter.com/wkwebview/status/608005652720451584 > > > > > > > > > > > > > > > On Monday, June 8, 2015, Shazron wrote: > > > > > > > > > >> Cordova developers rejoice, iOS 9 includes the API to load pages > > from > > > > >> file:// urls > > https://twitter.com/wkwebview/status/608002548151119872 > > > > >> > > > > >> On Mon, Feb 9, 2015 at 2:19 PM, Shazron > wrote: > > > > >> > > > > >>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade I > > > > >>> suppose for your dev machines and build servers... > > > > >>> > > > > >>> > > > > >>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams > > > > >>> wrote: > > > > >>> > Oh, FFS. > > > > >>> > > > > > >>> > I give up on Apple solving this, personally. Most apps don’t > > > > >>> *actually* need it (they think they do, but they don’t). I am > going > > > to > > > > find > > > > >>> another way to solve it for our apps… maybe I will actually have > to > > > > write a > > > > >>> native plugin for the crypto :( > > > > >>> > > > > > >>> > -- > > > > >>> > tommy-carlos williams > > > > >>> > > > > > >>> > On 10 February 2015 at 08:18:31, Shazron (shaz...@gmail.com) > > > wrote: > > > > >>> > > > > > >>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not* > > > contain > > > > >>> > the loadFileURL:readAccessURL: selector that we are all waiting > > for > > > > >>> > :'( > > > > >>> > https://twitter.com/wkwebview/status/564865657225756672 > > > > >>> > > > > >> > > > > >> > > > > > > > > > >
Re: [iOS 8] WKWebView moving forward
+1 to what Kerri said. If we did it, it would be in Library/Caches since that is not backed up by iTunes: https://developer.apple.com/library/ios/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html#//apple_ref/doc/uid/TP40010672-CH2-SW1 On Tue, Jun 9, 2015 at 1:58 PM, Kerri Shotts wrote: > Speaking as a user who has an iPhone that’s always running near the > storage limit: I’d hate to see files be duplicate out of the bundle into > another location… my phone might cry. > > I think we went over that when WKWebview was first released. Copying files > was discussed, but it adds an awful lot of complexity to startup, wastes > space, etc. Looks like the local web server might be the best option, still. > > But I guess this gives the option of using web content that the app itself > downloads to /Documents or /Library, so that could be nice. Unfortunate > that they hamstrung it regarding bundles tho. Here’s hoping they’ll change > it, but given the track record in iOS 8, I’m not holding my breath. > > > > > On June 9, 2015 at 3:50:09 PM, Ross Gerbasi (rgerb...@gmail.com) wrote: > > Would it be a horrible idea to copy files into one of those folders? > > On Tue, Jun 9, 2015 at 3:22 PM, Shazron wrote: > > > We could use it for InAppBrowser but we might lose some features that we > > have possibly. > > > > Anyways, one piece of bad news for WKWebView iOS 9 - you can load file > urls > > in Library and Documents, but not the app bundle. > > https://twitter.com/wkwebview/status/608359163299819521 > > > > On Tue, Jun 9, 2015 at 1:02 PM, Carlos Santana > > wrote: > > > > > Yay ! > > > There is also a new Safari View Controller, don't know if it's > applicable > > > to replace wkwebview but at least I think it can be use to build the > next > > > gen inappbrowser since its beats a makeup in iOS anyway. > > > > > > The session is in 30 minutes so I'm planning attending. > > > On Mon, Jun 8, 2015 at 2:33 PM Shazron wrote: > > > > > > > There is a WWDC session: "Safari Extensibility: Content Blocking and > > > Shared > > > > Links". So I'm hopeful for whitelisting > > > > > > > > On Mon, Jun 8, 2015 at 1:22 PM, Shazron wrote: > > > > > > > > > Moar news https://twitter.com/wkwebview/status/608005652720451584 > > > > > > > > > > > > > > > On Monday, June 8, 2015, Shazron wrote: > > > > > > > > > >> Cordova developers rejoice, iOS 9 includes the API to load pages > > from > > > > >> file:// urls > > https://twitter.com/wkwebview/status/608002548151119872 > > > > >> > > > > >> On Mon, Feb 9, 2015 at 2:19 PM, Shazron > wrote: > > > > >> > > > > >>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade I > > > > >>> suppose for your dev machines and build servers... > > > > >>> > > > > >>> > > > > >>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams > > > > >>> wrote: > > > > >>> > Oh, FFS. > > > > >>> > > > > > >>> > I give up on Apple solving this, personally. Most apps don’t > > > > >>> *actually* need it (they think they do, but they don’t). I am > going > > > to > > > > find > > > > >>> another way to solve it for our apps… maybe I will actually have > to > > > > write a > > > > >>> native plugin for the crypto :( > > > > >>> > > > > > >>> > -- > > > > >>> > tommy-carlos williams > > > > >>> > > > > > >>> > On 10 February 2015 at 08:18:31, Shazron (shaz...@gmail.com) > > > wrote: > > > > >>> > > > > > >>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not* > > > contain > > > > >>> > the loadFileURL:readAccessURL: selector that we are all waiting > > for > > > > >>> > :'( > > > > >>> > https://twitter.com/wkwebview/status/564865657225756672 > > > > >>> > > > > >> > > > > >> > > > > > > > > > >
Re: [iOS 8] WKWebView moving forward
Speaking as a user who has an iPhone that’s always running near the storage limit: I’d hate to see files be duplicate out of the bundle into another location… my phone might cry. I think we went over that when WKWebview was first released. Copying files was discussed, but it adds an awful lot of complexity to startup, wastes space, etc. Looks like the local web server might be the best option, still. But I guess this gives the option of using web content that the app itself downloads to /Documents or /Library, so that could be nice. Unfortunate that they hamstrung it regarding bundles tho. Here’s hoping they’ll change it, but given the track record in iOS 8, I’m not holding my breath. On June 9, 2015 at 3:50:09 PM, Ross Gerbasi (rgerb...@gmail.com) wrote: Would it be a horrible idea to copy files into one of those folders? On Tue, Jun 9, 2015 at 3:22 PM, Shazron wrote: > We could use it for InAppBrowser but we might lose some features that we > have possibly. > > Anyways, one piece of bad news for WKWebView iOS 9 - you can load file urls > in Library and Documents, but not the app bundle. > https://twitter.com/wkwebview/status/608359163299819521 > > On Tue, Jun 9, 2015 at 1:02 PM, Carlos Santana > wrote: > > > Yay ! > > There is also a new Safari View Controller, don't know if it's applicable > > to replace wkwebview but at least I think it can be use to build the next > > gen inappbrowser since its beats a makeup in iOS anyway. > > > > The session is in 30 minutes so I'm planning attending. > > On Mon, Jun 8, 2015 at 2:33 PM Shazron wrote: > > > > > There is a WWDC session: "Safari Extensibility: Content Blocking and > > Shared > > > Links". So I'm hopeful for whitelisting > > > > > > On Mon, Jun 8, 2015 at 1:22 PM, Shazron wrote: > > > > > > > Moar news https://twitter.com/wkwebview/status/608005652720451584 > > > > > > > > > > > > On Monday, June 8, 2015, Shazron wrote: > > > > > > > >> Cordova developers rejoice, iOS 9 includes the API to load pages > from > > > >> file:// urls > https://twitter.com/wkwebview/status/608002548151119872 > > > >> > > > >> On Mon, Feb 9, 2015 at 2:19 PM, Shazron wrote: > > > >> > > > >>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade I > > > >>> suppose for your dev machines and build servers... > > > >>> > > > >>> > > > >>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams > > > >>> wrote: > > > >>> > Oh, FFS. > > > >>> > > > > >>> > I give up on Apple solving this, personally. Most apps don’t > > > >>> *actually* need it (they think they do, but they don’t). I am going > > to > > > find > > > >>> another way to solve it for our apps… maybe I will actually have to > > > write a > > > >>> native plugin for the crypto :( > > > >>> > > > > >>> > -- > > > >>> > tommy-carlos williams > > > >>> > > > > >>> > On 10 February 2015 at 08:18:31, Shazron (shaz...@gmail.com) > > wrote: > > > >>> > > > > >>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not* > > contain > > > >>> > the loadFileURL:readAccessURL: selector that we are all waiting > for > > > >>> > :'( > > > >>> > https://twitter.com/wkwebview/status/564865657225756672 > > > >>> > > > >> > > > >> > > > > > >
Re: [iOS 8] WKWebView moving forward
Would it be a horrible idea to copy files into one of those folders? On Tue, Jun 9, 2015 at 3:22 PM, Shazron wrote: > We could use it for InAppBrowser but we might lose some features that we > have possibly. > > Anyways, one piece of bad news for WKWebView iOS 9 - you can load file urls > in Library and Documents, but not the app bundle. > https://twitter.com/wkwebview/status/608359163299819521 > > On Tue, Jun 9, 2015 at 1:02 PM, Carlos Santana > wrote: > > > Yay ! > > There is also a new Safari View Controller, don't know if it's applicable > > to replace wkwebview but at least I think it can be use to build the next > > gen inappbrowser since its beats a makeup in iOS anyway. > > > > The session is in 30 minutes so I'm planning attending. > > On Mon, Jun 8, 2015 at 2:33 PM Shazron wrote: > > > > > There is a WWDC session: "Safari Extensibility: Content Blocking and > > Shared > > > Links". So I'm hopeful for whitelisting > > > > > > On Mon, Jun 8, 2015 at 1:22 PM, Shazron wrote: > > > > > > > Moar news https://twitter.com/wkwebview/status/608005652720451584 > > > > > > > > > > > > On Monday, June 8, 2015, Shazron wrote: > > > > > > > >> Cordova developers rejoice, iOS 9 includes the API to load pages > from > > > >> file:// urls > https://twitter.com/wkwebview/status/608002548151119872 > > > >> > > > >> On Mon, Feb 9, 2015 at 2:19 PM, Shazron wrote: > > > >> > > > >>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade I > > > >>> suppose for your dev machines and build servers... > > > >>> > > > >>> > > > >>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams > > > >>> wrote: > > > >>> > Oh, FFS. > > > >>> > > > > >>> > I give up on Apple solving this, personally. Most apps don’t > > > >>> *actually* need it (they think they do, but they don’t). I am going > > to > > > find > > > >>> another way to solve it for our apps… maybe I will actually have to > > > write a > > > >>> native plugin for the crypto :( > > > >>> > > > > >>> > -- > > > >>> > tommy-carlos williams > > > >>> > > > > >>> > On 10 February 2015 at 08:18:31, Shazron (shaz...@gmail.com) > > wrote: > > > >>> > > > > >>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not* > > contain > > > >>> > the loadFileURL:readAccessURL: selector that we are all waiting > for > > > >>> > :'( > > > >>> > https://twitter.com/wkwebview/status/564865657225756672 > > > >>> > > > >> > > > >> > > > > > >
Re: [iOS 8] WKWebView moving forward
IndexedDB news is looking a bit bleak: https://gist.github.com/nolanlawson/08eb857c6b17a30c1b26 On 9 June 2015 at 13:28, Shazron wrote: > > Here's the juicy Safari iOS 9 bits, including new javascript and css > features, including SFSafariViewController: > https://developer.apple.com/library/prerelease/mac/releasenotes/General/WhatsNewInSafari/Articles/Safari_9.html > > On Tue, Jun 9, 2015 at 1:22 PM, Shazron wrote: > > > We could use it for InAppBrowser but we might lose some features that we > > have possibly. > > > > Anyways, one piece of bad news for WKWebView iOS 9 - you can load file > > urls in Library and Documents, but not the app bundle. > > https://twitter.com/wkwebview/status/608359163299819521 > > > > On Tue, Jun 9, 2015 at 1:02 PM, Carlos Santana > > wrote: > > > >> Yay ! > >> There is also a new Safari View Controller, don't know if it's applicable > >> to replace wkwebview but at least I think it can be use to build the next > >> gen inappbrowser since its beats a makeup in iOS anyway. > >> > >> The session is in 30 minutes so I'm planning attending. > >> On Mon, Jun 8, 2015 at 2:33 PM Shazron wrote: > >> > >> > There is a WWDC session: "Safari Extensibility: Content Blocking and > >> Shared > >> > Links". So I'm hopeful for whitelisting > >> > > >> > On Mon, Jun 8, 2015 at 1:22 PM, Shazron wrote: > >> > > >> > > Moar news https://twitter.com/wkwebview/status/608005652720451584 > >> > > > >> > > > >> > > On Monday, June 8, 2015, Shazron wrote: > >> > > > >> > >> Cordova developers rejoice, iOS 9 includes the API to load pages from > >> > >> file:// urls https://twitter.com/wkwebview/status/608002548151119872 > >> > >> > >> > >> On Mon, Feb 9, 2015 at 2:19 PM, Shazron wrote: > >> > >> > >> > >>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade I > >> > >>> suppose for your dev machines and build servers... > >> > >>> > >> > >>> > >> > >>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams > >> > >>> wrote: > >> > >>> > Oh, FFS. > >> > >>> > > >> > >>> > I give up on Apple solving this, personally. Most apps don’t > >> > >>> *actually* need it (they think they do, but they don’t). I am going > >> to > >> > find > >> > >>> another way to solve it for our apps… maybe I will actually have to > >> > write a > >> > >>> native plugin for the crypto :( > >> > >>> > > >> > >>> > -- > >> > >>> > tommy-carlos williams > >> > >>> > > >> > >>> > On 10 February 2015 at 08:18:31, Shazron (shaz...@gmail.com) > >> wrote: > >> > >>> > > >> > >>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not* > >> contain > >> > >>> > the loadFileURL:readAccessURL: selector that we are all waiting > >> for > >> > >>> > :'( > >> > >>> > https://twitter.com/wkwebview/status/564865657225756672 > >> > >>> > >> > >> > >> > >> > >> > > >> > > > > - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [iOS 8] WKWebView moving forward
Here's the juicy Safari iOS 9 bits, including new javascript and css features, including SFSafariViewController: https://developer.apple.com/library/prerelease/mac/releasenotes/General/WhatsNewInSafari/Articles/Safari_9.html On Tue, Jun 9, 2015 at 1:22 PM, Shazron wrote: > We could use it for InAppBrowser but we might lose some features that we > have possibly. > > Anyways, one piece of bad news for WKWebView iOS 9 - you can load file > urls in Library and Documents, but not the app bundle. > https://twitter.com/wkwebview/status/608359163299819521 > > On Tue, Jun 9, 2015 at 1:02 PM, Carlos Santana > wrote: > >> Yay ! >> There is also a new Safari View Controller, don't know if it's applicable >> to replace wkwebview but at least I think it can be use to build the next >> gen inappbrowser since its beats a makeup in iOS anyway. >> >> The session is in 30 minutes so I'm planning attending. >> On Mon, Jun 8, 2015 at 2:33 PM Shazron wrote: >> >> > There is a WWDC session: "Safari Extensibility: Content Blocking and >> Shared >> > Links". So I'm hopeful for whitelisting >> > >> > On Mon, Jun 8, 2015 at 1:22 PM, Shazron wrote: >> > >> > > Moar news https://twitter.com/wkwebview/status/608005652720451584 >> > > >> > > >> > > On Monday, June 8, 2015, Shazron wrote: >> > > >> > >> Cordova developers rejoice, iOS 9 includes the API to load pages from >> > >> file:// urls https://twitter.com/wkwebview/status/608002548151119872 >> > >> >> > >> On Mon, Feb 9, 2015 at 2:19 PM, Shazron wrote: >> > >> >> > >>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade I >> > >>> suppose for your dev machines and build servers... >> > >>> >> > >>> >> > >>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams >> > >>> wrote: >> > >>> > Oh, FFS. >> > >>> > >> > >>> > I give up on Apple solving this, personally. Most apps don’t >> > >>> *actually* need it (they think they do, but they don’t). I am going >> to >> > find >> > >>> another way to solve it for our apps… maybe I will actually have to >> > write a >> > >>> native plugin for the crypto :( >> > >>> > >> > >>> > -- >> > >>> > tommy-carlos williams >> > >>> > >> > >>> > On 10 February 2015 at 08:18:31, Shazron (shaz...@gmail.com) >> wrote: >> > >>> > >> > >>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not* >> contain >> > >>> > the loadFileURL:readAccessURL: selector that we are all waiting >> for >> > >>> > :'( >> > >>> > https://twitter.com/wkwebview/status/564865657225756672 >> > >>> >> > >> >> > >> >> > >> > >
Re: [iOS 8] WKWebView moving forward
We could use it for InAppBrowser but we might lose some features that we have possibly. Anyways, one piece of bad news for WKWebView iOS 9 - you can load file urls in Library and Documents, but not the app bundle. https://twitter.com/wkwebview/status/608359163299819521 On Tue, Jun 9, 2015 at 1:02 PM, Carlos Santana wrote: > Yay ! > There is also a new Safari View Controller, don't know if it's applicable > to replace wkwebview but at least I think it can be use to build the next > gen inappbrowser since its beats a makeup in iOS anyway. > > The session is in 30 minutes so I'm planning attending. > On Mon, Jun 8, 2015 at 2:33 PM Shazron wrote: > > > There is a WWDC session: "Safari Extensibility: Content Blocking and > Shared > > Links". So I'm hopeful for whitelisting > > > > On Mon, Jun 8, 2015 at 1:22 PM, Shazron wrote: > > > > > Moar news https://twitter.com/wkwebview/status/608005652720451584 > > > > > > > > > On Monday, June 8, 2015, Shazron wrote: > > > > > >> Cordova developers rejoice, iOS 9 includes the API to load pages from > > >> file:// urls https://twitter.com/wkwebview/status/608002548151119872 > > >> > > >> On Mon, Feb 9, 2015 at 2:19 PM, Shazron wrote: > > >> > > >>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade I > > >>> suppose for your dev machines and build servers... > > >>> > > >>> > > >>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams > > >>> wrote: > > >>> > Oh, FFS. > > >>> > > > >>> > I give up on Apple solving this, personally. Most apps don’t > > >>> *actually* need it (they think they do, but they don’t). I am going > to > > find > > >>> another way to solve it for our apps… maybe I will actually have to > > write a > > >>> native plugin for the crypto :( > > >>> > > > >>> > -- > > >>> > tommy-carlos williams > > >>> > > > >>> > On 10 February 2015 at 08:18:31, Shazron (shaz...@gmail.com) > wrote: > > >>> > > > >>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not* > contain > > >>> > the loadFileURL:readAccessURL: selector that we are all waiting for > > >>> > :'( > > >>> > https://twitter.com/wkwebview/status/564865657225756672 > > >>> > > >> > > >> > > >
Re: [iOS 8] WKWebView moving forward
Yay ! There is also a new Safari View Controller, don't know if it's applicable to replace wkwebview but at least I think it can be use to build the next gen inappbrowser since its beats a makeup in iOS anyway. The session is in 30 minutes so I'm planning attending. On Mon, Jun 8, 2015 at 2:33 PM Shazron wrote: > There is a WWDC session: "Safari Extensibility: Content Blocking and Shared > Links". So I'm hopeful for whitelisting > > On Mon, Jun 8, 2015 at 1:22 PM, Shazron wrote: > > > Moar news https://twitter.com/wkwebview/status/608005652720451584 > > > > > > On Monday, June 8, 2015, Shazron wrote: > > > >> Cordova developers rejoice, iOS 9 includes the API to load pages from > >> file:// urls https://twitter.com/wkwebview/status/608002548151119872 > >> > >> On Mon, Feb 9, 2015 at 2:19 PM, Shazron wrote: > >> > >>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade I > >>> suppose for your dev machines and build servers... > >>> > >>> > >>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams > >>> wrote: > >>> > Oh, FFS. > >>> > > >>> > I give up on Apple solving this, personally. Most apps don’t > >>> *actually* need it (they think they do, but they don’t). I am going to > find > >>> another way to solve it for our apps… maybe I will actually have to > write a > >>> native plugin for the crypto :( > >>> > > >>> > -- > >>> > tommy-carlos williams > >>> > > >>> > On 10 February 2015 at 08:18:31, Shazron (shaz...@gmail.com) wrote: > >>> > > >>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not* contain > >>> > the loadFileURL:readAccessURL: selector that we are all waiting for > >>> > :'( > >>> > https://twitter.com/wkwebview/status/564865657225756672 > >>> > >> > >> >
Re: [iOS 8] WKWebView moving forward
There is a WWDC session: "Safari Extensibility: Content Blocking and Shared Links". So I'm hopeful for whitelisting On Mon, Jun 8, 2015 at 1:22 PM, Shazron wrote: > Moar news https://twitter.com/wkwebview/status/608005652720451584 > > > On Monday, June 8, 2015, Shazron wrote: > >> Cordova developers rejoice, iOS 9 includes the API to load pages from >> file:// urls https://twitter.com/wkwebview/status/608002548151119872 >> >> On Mon, Feb 9, 2015 at 2:19 PM, Shazron wrote: >> >>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade I >>> suppose for your dev machines and build servers... >>> >>> >>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams >>> wrote: >>> > Oh, FFS. >>> > >>> > I give up on Apple solving this, personally. Most apps don’t >>> *actually* need it (they think they do, but they don’t). I am going to find >>> another way to solve it for our apps… maybe I will actually have to write a >>> native plugin for the crypto :( >>> > >>> > -- >>> > tommy-carlos williams >>> > >>> > On 10 February 2015 at 08:18:31, Shazron (shaz...@gmail.com) wrote: >>> > >>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not* contain >>> > the loadFileURL:readAccessURL: selector that we are all waiting for >>> > :'( >>> > https://twitter.com/wkwebview/status/564865657225756672 >>> >> >>
Re: [iOS 8] WKWebView moving forward
Moar news https://twitter.com/wkwebview/status/608005652720451584 On Monday, June 8, 2015, Shazron wrote: > Cordova developers rejoice, iOS 9 includes the API to load pages from > file:// urls https://twitter.com/wkwebview/status/608002548151119872 > > On Mon, Feb 9, 2015 at 2:19 PM, Shazron > wrote: > >> Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade I >> suppose for your dev machines and build servers... >> >> >> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams >> > >> wrote: >> > Oh, FFS. >> > >> > I give up on Apple solving this, personally. Most apps don’t *actually* >> need it (they think they do, but they don’t). I am going to find another >> way to solve it for our apps… maybe I will actually have to write a native >> plugin for the crypto :( >> > >> > -- >> > tommy-carlos williams >> > >> > On 10 February 2015 at 08:18:31, Shazron (shaz...@gmail.com >> ) wrote: >> > >> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not* contain >> > the loadFileURL:readAccessURL: selector that we are all waiting for >> > :'( >> > https://twitter.com/wkwebview/status/564865657225756672 >> > >
Re: [iOS 8] WKWebView moving forward
No idea yet Darryl On Monday, June 8, 2015, Darryl Pogue wrote: > Any news on IndexedDB bug fixes? Or working URL interceptors? > > On 8 June 2015 at 13:13, Shazron > wrote: > > Cordova developers rejoice, iOS 9 includes the API to load pages from > > file:// urls https://twitter.com/wkwebview/status/608002548151119872 > > > > On Mon, Feb 9, 2015 at 2:19 PM, Shazron > wrote: > > > >> Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade I > >> suppose for your dev machines and build servers... > >> > >> > >> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams > >> > wrote: > >> > Oh, FFS. > >> > > >> > I give up on Apple solving this, personally. Most apps don’t > *actually* > >> need it (they think they do, but they don’t). I am going to find another > >> way to solve it for our apps… maybe I will actually have to write a > native > >> plugin for the crypto :( > >> > > >> > -- > >> > tommy-carlos williams > >> > > >> > On 10 February 2015 at 08:18:31, Shazron (shaz...@gmail.com > ) wrote: > >> > > >> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not* contain > >> > the loadFileURL:readAccessURL: selector that we are all waiting for > >> > :'( > >> > https://twitter.com/wkwebview/status/564865657225756672 > >> > > - > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > > >
Re: [iOS 8] WKWebView moving forward
Why am I hearing the Hallelujah chorus? I’m dong my happy dance now! :-) On June 8, 2015 at 3:14:14 PM, Shazron (shaz...@gmail.com) wrote: Cordova developers rejoice, iOS 9 includes the API to load pages from file:// urls https://twitter.com/wkwebview/status/608002548151119872 On Mon, Feb 9, 2015 at 2:19 PM, Shazron wrote: > Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade I > suppose for your dev machines and build servers... > > > On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams > wrote: > > Oh, FFS. > > > > I give up on Apple solving this, personally. Most apps don’t *actually* > need it (they think they do, but they don’t). I am going to find another > way to solve it for our apps… maybe I will actually have to write a native > plugin for the crypto :( > > > > -- > > tommy-carlos williams > > > > On 10 February 2015 at 08:18:31, Shazron (shaz...@gmail.com) wrote: > > > > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not* contain > > the loadFileURL:readAccessURL: selector that we are all waiting for > > :'( > > https://twitter.com/wkwebview/status/564865657225756672 >
Re: [iOS 8] WKWebView moving forward
Any news on IndexedDB bug fixes? Or working URL interceptors? On 8 June 2015 at 13:13, Shazron wrote: > Cordova developers rejoice, iOS 9 includes the API to load pages from > file:// urls https://twitter.com/wkwebview/status/608002548151119872 > > On Mon, Feb 9, 2015 at 2:19 PM, Shazron wrote: > >> Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade I >> suppose for your dev machines and build servers... >> >> >> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams >> wrote: >> > Oh, FFS. >> > >> > I give up on Apple solving this, personally. Most apps don’t *actually* >> need it (they think they do, but they don’t). I am going to find another >> way to solve it for our apps… maybe I will actually have to write a native >> plugin for the crypto :( >> > >> > -- >> > tommy-carlos williams >> > >> > On 10 February 2015 at 08:18:31, Shazron (shaz...@gmail.com) wrote: >> > >> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not* contain >> > the loadFileURL:readAccessURL: selector that we are all waiting for >> > :'( >> > https://twitter.com/wkwebview/status/564865657225756672 >> - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [iOS 8] WKWebView moving forward
Cordova developers rejoice, iOS 9 includes the API to load pages from file:// urls https://twitter.com/wkwebview/status/608002548151119872 On Mon, Feb 9, 2015 at 2:19 PM, Shazron wrote: > Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade I > suppose for your dev machines and build servers... > > > On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams > wrote: > > Oh, FFS. > > > > I give up on Apple solving this, personally. Most apps don’t *actually* > need it (they think they do, but they don’t). I am going to find another > way to solve it for our apps… maybe I will actually have to write a native > plugin for the crypto :( > > > > -- > > tommy-carlos williams > > > > On 10 February 2015 at 08:18:31, Shazron (shaz...@gmail.com) wrote: > > > > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not* contain > > the loadFileURL:readAccessURL: selector that we are all waiting for > > :'( > > https://twitter.com/wkwebview/status/564865657225756672 >
Re: [iOS 8] WKWebView moving forward
Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade I suppose for your dev machines and build servers... On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams wrote: > Oh, FFS. > > I give up on Apple solving this, personally. Most apps don’t *actually* need > it (they think they do, but they don’t). I am going to find another way to > solve it for our apps… maybe I will actually have to write a native plugin > for the crypto :( > > -- > tommy-carlos williams > > On 10 February 2015 at 08:18:31, Shazron (shaz...@gmail.com) wrote: > > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not* contain > the loadFileURL:readAccessURL: selector that we are all waiting for > :'( > https://twitter.com/wkwebview/status/564865657225756672 - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [iOS 8] WKWebView moving forward
Oh, FFS. I give up on Apple solving this, personally. Most apps don’t *actually* need it (they think they do, but they don’t). I am going to find another way to solve it for our apps… maybe I will actually have to write a native plugin for the crypto :( -- tommy-carlos williams On 10 February 2015 at 08:18:31, Shazron (shaz...@gmail.com) wrote: In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not* contain the loadFileURL:readAccessURL: selector that we are all waiting for :'( https://twitter.com/wkwebview/status/564865657225756672
Re: [iOS 8] WKWebView moving forward
Some have been asking -- why not use that Telerik plugin? 1. Swizzling will potentially come with some headaches in the future. As it is currently, the Telerik plugin swaps implementations for an AppDelegate function. So whatever changes we have in the AppDelegate function in the future, it will be lost. The plugin could call the old implementation as well (it does not do so currently), but of course this could create problems as is. This would be hard to maintain with potential future changes. 2. The Telerik plugin will not work if you have any file:// url references when using the core Camera and File plugins. The pluggable webview (wkwebview-engine) and local httpserver proposed will have a solution for this (still a work in progress, needs testing). The Telerik plugin can of course copy from our proposed code to solve this problem. Blog post upcoming, I think, where I can just gather all info regarding the planned work -- for the general public and not just us devs. On Mon, Feb 9, 2015 at 11:23 AM, Shazron wrote: > Darryl: That plugin, based on inspection, is based off my work in > progress code (also used to be based off tmp loading, but now uses the > same httpserver method). The major thing I can see they added was > swizzling an AppDelegate method so it can work on any 3.x cordova-ios. > > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not* contain > the loadFileURL:readAccessURL: selector that we are all waiting for > :'( > https://twitter.com/wkwebview/status/564865657225756672 > > On Wed, Dec 10, 2014 at 10:28 PM, Darryl Pogue wrote: >> On 10 December 2014 at 22:20, Ally Ogilvie wrote: >>> >>> @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 >>> >> >> There's also a Telerik plugin for WkWebView support: >> https://github.com/Telerik-Verified-Plugins/WKWebView >> >> It seems to do roughly the same thing that Shazron's been working on >> (serving from a local HTTP server rather than from file). >> >> - >> 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
Re: [iOS 8] WKWebView moving forward
Darryl: That plugin, based on inspection, is based off my work in progress code (also used to be based off tmp loading, but now uses the same httpserver method). The major thing I can see they added was swizzling an AppDelegate method so it can work on any 3.x cordova-ios. In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not* contain the loadFileURL:readAccessURL: selector that we are all waiting for :'( https://twitter.com/wkwebview/status/564865657225756672 On Wed, Dec 10, 2014 at 10:28 PM, Darryl Pogue wrote: > On 10 December 2014 at 22:20, Ally Ogilvie wrote: >> >> @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 >> > > There's also a Telerik plugin for WkWebView support: > https://github.com/Telerik-Verified-Plugins/WKWebView > > It seems to do roughly the same thing that Shazron's been working on > (serving from a local HTTP server rather than from file). > > - > 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
Re: [iOS 8] WKWebView moving forward
On 10 December 2014 at 22:20, Ally Ogilvie wrote: > > @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 > There's also a Telerik plugin for WkWebView support: https://github.com/Telerik-Verified-Plugins/WKWebView It seems to do roughly the same thing that Shazron's been working on (serving from a local HTTP server rather than from file). - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [iOS 8] WKWebView moving forward
@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 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 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 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 > > 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" 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 > > >> >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" 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 > > > >> >>wrote: > > >> >> >> > > >>
Re: [iOS 8] WKWebView moving forward
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 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 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
> 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" 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
> >> >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" 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
> >> >>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 relevan
Re: [iOS 8] WKWebView moving forward
Pretty sure they are saving it for the "and one last thing" part of the iOS
10 release :P
On Wed, Dec 10, 2014 at 6:18 PM, Shazron 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 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
> 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" 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
> >> >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" 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
> >> >>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.
> >
Re: [iOS 8] WKWebView moving forward
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 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 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" 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
>> >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" 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
>> >> >wrote:
>> >> >
>> >> >> On Tue Nov 18 2014 at 2:00:34 PM Jesse
>> >>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
>> >> >>
>> >> >>
>> >> >> >
>>
Re: [iOS 8] WKWebView moving forward
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 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" 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
> >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" 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
> >> >wrote:
> >> >
> >> >> On Tue Nov 18 2014 at 2:00:34 PM Jesse
> >>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
> >> >> >
> >> >> > 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 = [co
Re: [iOS 8] WKWebView moving forward
Whew :) On 21/11/2014 12:58 am, "Homer, Tony" wrote: > Thanks for asking, Tommy. Shazron’s original security caveat was: > "Any backgrounded app can potentially access this local web server when > your app is running.” > > My PR made 2 changes: > 1. restrict requests to localhost > 2. provide for and require that a security token be included in the request > > I needed to update the security caveat as part of the PR, but I didn’t > want to oversell the fix! > Up until now, I thought localhost packets worked just like any other > packets and would be visible to a network sniffer. > However, after reading your question and doing a little searching, it > seems that is incorrect. > From http://en.wikipedia.org/wiki/Localhost#Name_resolution: > > "The processing of any packets sent to a loopback address is implemented > in the link layer of the TCP/IP stack. Such packets are never delivered to > any network interface controller (NIC) or device driver" > > I guess we can drop that sentence from the security caveat. > I’ll submit a PR. > > Tony > > On 11/19/14, 7:30 PM, "Shazron" wrote: > > >I'm not sure - Tony wrote that part maybe he can explain the intricacies. > > > >On Wed, Nov 19, 2014 at 4:23 PM, tommy-carlos williams > > > >wrote: > > > >> Shazron, > >> > >> I just noticed this in the README for the plugin: > >> > >> "However, since requests are made over http, your app's activity may be > >> visible to others on the name wi-fi network.” > >> > >> Is this actually true? Why would traffic to localhost leave the device > >>and > >> be visible over the wifi? > >> > >> > >> > >> -- > >> tommy-carlos williams > >> > >> On 20 November 2014 at 08:18:28, 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" 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 > >> >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" 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#co > >mm > >> >>>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 > >> > >> >> >wrote: > >> >> > > >> >> >> On
Re: [iOS 8] WKWebView moving forward
Thanks for asking, Tommy. Shazron’s original security caveat was:
"Any backgrounded app can potentially access this local web server when
your app is running.”
My PR made 2 changes:
1. restrict requests to localhost
2. provide for and require that a security token be included in the request
I needed to update the security caveat as part of the PR, but I didn’t
want to oversell the fix!
Up until now, I thought localhost packets worked just like any other
packets and would be visible to a network sniffer.
However, after reading your question and doing a little searching, it
seems that is incorrect.
From http://en.wikipedia.org/wiki/Localhost#Name_resolution:
"The processing of any packets sent to a loopback address is implemented
in the link layer of the TCP/IP stack. Such packets are never delivered to
any network interface controller (NIC) or device driver"
I guess we can drop that sentence from the security caveat.
I’ll submit a PR.
Tony
On 11/19/14, 7:30 PM, "Shazron" wrote:
>I'm not sure - Tony wrote that part maybe he can explain the intricacies.
>
>On Wed, Nov 19, 2014 at 4:23 PM, tommy-carlos williams
>
>wrote:
>
>> Shazron,
>>
>> I just noticed this in the README for the plugin:
>>
>> "However, since requests are made over http, your app's activity may be
>> visible to others on the name wi-fi network.”
>>
>> Is this actually true? Why would traffic to localhost leave the device
>>and
>> be visible over the wifi?
>>
>>
>>
>> --
>> tommy-carlos williams
>>
>> On 20 November 2014 at 08:18:28, 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" 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
>> >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" 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#co
>mm
>> >>>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
>>
>> >> >wrote:
>> >> >
>> >> >> On Tue Nov 18 2014 at 2:00:34 PM Jesse
>> >>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, other
Re: [iOS 8] WKWebView moving forward
I'm not sure - Tony wrote that part maybe he can explain the intricacies.
On Wed, Nov 19, 2014 at 4:23 PM, tommy-carlos williams
wrote:
> Shazron,
>
> I just noticed this in the README for the plugin:
>
> "However, since requests are made over http, your app's activity may be
> visible to others on the name wi-fi network.”
>
> Is this actually true? Why would traffic to localhost leave the device and
> be visible over the wifi?
>
>
>
> --
> tommy-carlos williams
>
> On 20 November 2014 at 08:18:28, 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" 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
> >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" 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
> >> >wrote:
> >> >
> >> >> On Tue Nov 18 2014 at 2:00:34 PM Jesse
> >>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
Re: [iOS 8] WKWebView moving forward
Shazron,
I just noticed this in the README for the plugin:
"However, since requests are made over http, your app's activity may be visible
to others on the name wi-fi network.”
Is this actually true? Why would traffic to localhost leave the device and be
visible over the wifi?
--
tommy-carlos williams
On 20 November 2014 at 08:18:28, 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" 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
>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" 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
>> >wrote:
>> >
>> >> On Tue Nov 18 2014 at 2:00:34 PM Jesse
>>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
>>> >
>> >> > wrote:
>> >> >
>> >> > > Having the localserver plugin add behaviour to file plugin feels
>> >>like
>> >> the
>> >> > > depend
Re: [iOS 8] WKWebView moving forward
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" 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
>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" 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
>> >wrote:
>> >
>> >> On Tue Nov 18 2014 at 2:00:34 PM Jesse
>>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
>>> >
>> >> > 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
>> wrote:
>> >> > >
>> >> > > > Filed https://issues.apache.org/jira/b
Re: [iOS 8] WKWebView moving forward
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 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" wrote:
>
> >I commented on Ian's comment on CB-8032:
> >
> https://issues.apache.org/jira/browse/CB-8032?focusedCommentId=14216403&pa
> >ge=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#commen
> >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
> >wrote:
> >
> >> On Tue Nov 18 2014 at 2:00:34 PM Jesse 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 >
> >> > 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
> wrote:
> >> > >
> >> > > > Filed https://issues.apache.org/jira/browse/CB-8032 with pull
> >> request
> >> > > > included.
> >> > > >
> >> > > > On Mon, Nov 17, 2014 at 2:47 PM, Shazron
> >>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 categor
Re: [iOS 8] WKWebView moving forward
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" wrote:
>I commented on Ian's comment on CB-8032:
>https://issues.apache.org/jira/browse/CB-8032?focusedCommentId=14216403&pa
>ge=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#commen
>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
>wrote:
>
>> On Tue Nov 18 2014 at 2:00:34 PM Jesse 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
>> > 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 wrote:
>> > >
>> > > > Filed https://issues.apache.org/jira/browse/CB-8032 with pull
>> request
>> > > > included.
>> > > >
>> > > > On Mon, Nov 17, 2014 at 2:47 PM, Shazron
>>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
>> wrote:
>> > > > >
>> > > > >> Local Web
Re: [iOS 8] WKWebView moving forward
Really Apple? Really? Hisss! Never mind my fangs. I've just dealt with a little too much Apple silliness as of late. (G.) ;-) On Wednesday, November 19, 2014, Shazron wrote: > Also, cue *sad violin*: the Xcode 6.2 beta SDK (iOS 8.2) does *not* include > the WKWebView loadFileURL:readAccessURL: method. > > > -- ___ *Kerri Shotts* photoKandy Studios, LLC On the Web: http://www.photokandy.com/ *Social Media:* Twitter: @photokandy, http://twitter.com/photokandy App.net: @photokandy, https://alpha.app.net/photokandy Google+: https://plus.google.com/110429856422449500918/posts Facebook: https://www.facebook.com/photoKandy Behance: https://www.behance.net/kerrishotts Tumblr: http://photokandy.tumblr.com/ Github: https://github.com/kerrishotts https://github.com/organizations/photokandyStudios CoderWall: https://coderwall.com/kerrishotts Stack Overflow: http://stackoverflow.com/users/741043/kerri-shotts *Apps on the Apple Store:* Greek Interlinear Bible 1.3: https://itunes.apple.com/us/artist/photokandy-studios-llc/id498577828 *Books:* PhoneGap 3.x Mobile Application Development Hotshot: http://www.photokandy.com/books/phonegap-3-x-hotshot/ PhoneGap 2.x Mobile Application Development Hotshot: http://www.photokandy.com/books/phonegap-2-x-hotshot/ Instant PhoneGap Social Application Development: http://www.photokandy.com/books/instant-social-app/
Re: [iOS 8] WKWebView moving forward
Also, cue *sad violin*: the Xcode 6.2 beta SDK (iOS 8.2) does *not* include
the WKWebView loadFileURL:readAccessURL: method.
On Wed, Nov 19, 2014 at 9:19 AM, Shazron wrote:
> I commented on Ian's comment on CB-8032:
> https://issues.apache.org/jira/browse/CB-8032?focusedCommentId=14216403&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-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
> wrote:
>
>> On Tue Nov 18 2014 at 2:00:34 PM Jesse 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
>> > 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 wrote:
>> > >
>> > > > Filed https://issues.apache.org/jira/browse/CB-8032 with pull
>> request
>> > > > included.
>> > > >
>> > > > On Mon, Nov 17, 2014 at 2:47 PM, Shazron 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
>> 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
>
Re: [iOS 8] WKWebView moving forward
I commented on Ian's comment on CB-8032:
https://issues.apache.org/jira/browse/CB-8032?focusedCommentId=14216403&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-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
wrote:
> On Tue Nov 18 2014 at 2:00:34 PM Jesse 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
> > 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 wrote:
> > >
> > > > Filed https://issues.apache.org/jira/browse/CB-8032 with pull
> request
> > > > included.
> > > >
> > > > On Mon, Nov 17, 2014 at 2:47 PM, Shazron 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
> 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
Re: [iOS 8] WKWebView moving forward
Since the last time I commented on this thread, I came across something
new (to me) that might work.
How about adding a custom NSURLProtocol to the LocalWebServer plugin and
setting it on the ?
This would allow the WebServer to intercept and redirect problematic
requests.
I just fixed a WebView caching bug in an app by adding a custom protocol.
In that case, I needed to intercept both the request and the response.
For this case we would
(1) intercept each request
(2) check if it matched a pattern
(3) if it matched the pattern, effectively redirect the request to the
local web server
This approach might require that a hook be added so that the custom
NSURLProtocol can be set at the right time, will have to check that.
I could put together a pull request to demonstrate, if it sounds worth
considering?
Tony
On 11/19/14, 9:20 AM, "Ian Clelland" wrote:
>On Tue Nov 18 2014 at 2:00:34 PM Jesse 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
>> 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 wrote:
>> >
>> > > Filed https://issues.apache.org/jira/browse/CB-8032 with pull
>>request
>> > > included.
>> > >
>> > > On Mon, Nov 17, 2014 at 2:47 PM, Shazron 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
>>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>
>> > > >> wro
Re: [iOS 8] WKWebView moving forward
On Tue Nov 18 2014 at 2:00:34 PM Jesse 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
> 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 wrote:
> >
> > > Filed https://issues.apache.org/jira/browse/CB-8032 with pull request
> > > included.
> > >
> > > On Mon, Nov 17, 2014 at 2:47 PM, Shazron 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 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 ).
> > > >>>
> > > >>> 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-
Re: [iOS 8] WKWebView moving forward
The reason I think it's the wrong way around is that: What if other plugins
want to work with localwebserver? Does each plugin wanting to work with it
send a PR to localwebserver for it to add a category to them?
On Tue, Nov 18, 2014 at 10:59 AM, Jesse 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.
>
> @purplecabbage
> risingj.com
>
> On Tue, Nov 18, 2014 at 10:42 AM, Andrew Grieve
> 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 wrote:
> >
> > > Filed https://issues.apache.org/jira/browse/CB-8032 with pull request
> > > included.
> > >
> > > On Mon, Nov 17, 2014 at 2:47 PM, Shazron 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 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 ).
> > > >>>
> > > >>> 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.
> > > >>>
> > > >>
Re: [iOS 8] WKWebView moving forward
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.
@purplecabbage
risingj.com
On Tue, Nov 18, 2014 at 10:42 AM, Andrew Grieve
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 wrote:
>
> > Filed https://issues.apache.org/jira/browse/CB-8032 with pull request
> > included.
> >
> > On Mon, Nov 17, 2014 at 2:47 PM, Shazron 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 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
> > >> 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 ).
> > >>>
> > >>> 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 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.
>
Re: [iOS 8] WKWebView moving forward
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 wrote:
> Filed https://issues.apache.org/jira/browse/CB-8032 with pull request
> included.
>
> On Mon, Nov 17, 2014 at 2:47 PM, Shazron 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 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
> >> 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 ).
> >>>
> >>> 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 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
> >>> > 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" 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 ab
Re: [iOS 8] WKWebView moving forward
Filed https://issues.apache.org/jira/browse/CB-8032 with pull request
included.
On Mon, Nov 17, 2014 at 2:47 PM, Shazron 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 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
>> 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 ).
>>>
>>> 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 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
>>> > 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" 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
>>> > > >
Re: [iOS 8] WKWebView moving forward
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 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
> 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 ).
>>
>> 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 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
>> > 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" 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 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).
>>
Re: [iOS 8] WKWebView moving forward
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 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 ). > > 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 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 > > 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" 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 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
Re: [iOS 8] WKWebView moving forward
le *sigh* :-( ___ *Kerri Shotts* photoKandy Studios, LLC
Re: [iOS 8] WKWebView moving forward
Tony" wrote: > > > >> >> > > > >> >> >I started looking at how to make the camera plugin be able to > work > > > in > > > >> >> >WKWebView. > > > >> >> >Before, I had mentioned intercepting resource requests as a way > to > > > fix > > > >> >>the > > > >> >> >file:// requests. > > > >> >> >However, WKWebView does not offer a way to intercept resource > > > requests > > > >> >>so > > > >> >> >that won’t work. > > > >> >> >:/ > > > >> >> > > > > >> >> >Andrew had suggested introducing some proxy paths as a way to > deal > > > >> with > > > >> >> >the path problems, which seems fine. > > > >> >> >On the other hand, the request handlers could just inspect the > > path > > > in > > > >> >>the > > > >> >> >request and do the right thing - are the proxy paths needed? > > > >> >> >I think implicit in those comments was a suggestion that the > > > affected > > > >> >> >plugins such as camera could return URLs using those paths. > > > >> >> >The thing about changing camera and file plugins to support > > > localhost > > > >> >>that > > > >> >> >bothers me, is that now those core plugins effectively support a > > > >> >>non-core > > > >> >> >plugin. > > > >> >> >Also, other (on-cordova) plugins that depend on file protocol > will > > > be > > > >> >> >incompatible with the local web server wkwebview solution > (unless > > > they > > > >> >> >make changes to support it). > > > >> >> > > > > >> >> >I wonder if it would be better to handle this in > CDVPluginResult? > > > >> >> >A hook could be added to initWithStatus and exposed to plugins. > > > >> >> >Then the SALocalWebServer plugin can use the hook to inspect the > > > >> >>message > > > >> >> >and fix it, if it is a file:// URL. > > > >> >> >So, for example, when camera calls CDVPluginResult > > > >> >> >resultWithStatus:messageAsString and passes in a file URL, > > > >> >>SALocalServer > > > >> >> >can get a chance to inspect and modify the result – changing it > to > > > an > > > >> >> >http:localhost URL. It could simply replace the file protocol > with > > > >> >> >http://localhost:port, then the handler could decode the path > > > before > > > >> >> >building the response. > > > >> >> >This is ugly, but it would prevent the need to change the camera > > and > > > >> >>file > > > >> >> >and should allow other non-cordova plugins that depend on > file:// > > > URLs > > > >> >>to > > > >> >> >work. > > > >> >> > > > > >> >> > > > > >> >> >Tony > > > >> >> > > > > >> >> >On 10/31/14, 2:03 PM, "Homer, Tony" > wrote: > > > >> >> > > > > >> >> >>I started with cookies in my POC, but I was concerned about > > replay > > > >> >> >>attacks. > > > >> >> >>I couldn’t think of a way to avoid replay vulnerability with > > > cookies > > > >> >> >>(without SSL), so I was going to switch to the side channel > > > approach > > > >> I > > > >> >> >>tried to describe. Do you think replay vulnerability is > > > irrelevant? > > > >> >>I’m > > > >> >> >>not a security guy, so I wasn’t sure if it mattered or not. > > That’s > > > >> >> >>actually one of the things I was hoping to get feedback about. > > > >> >> >> > > > >> >> >>I guess I don’t follow how CORS relates to the camera plugin, > > does > > > it > > > >> >>use > > > >> >> >>XHR? Maybe you can elaborate? > > > &
Re: [iOS 8] WKWebView moving forward
st inspect the > path > > in > > >> >>the > > >> >> >request and do the right thing - are the proxy paths needed? > > >> >> >I think implicit in those comments was a suggestion that the > > affected > > >> >> >plugins such as camera could return URLs using those paths. > > >> >> >The thing about changing camera and file plugins to support > > localhost > > >> >>that > > >> >> >bothers me, is that now those core plugins effectively support a > > >> >>non-core > > >> >> >plugin. > > >> >> >Also, other (on-cordova) plugins that depend on file protocol will > > be > > >> >> >incompatible with the local web server wkwebview solution (unless > > they > > >> >> >make changes to support it). > > >> >> > > > >> >> >I wonder if it would be better to handle this in CDVPluginResult? > > >> >> >A hook could be added to initWithStatus and exposed to plugins. > > >> >> >Then the SALocalWebServer plugin can use the hook to inspect the > > >> >>message > > >> >> >and fix it, if it is a file:// URL. > > >> >> >So, for example, when camera calls CDVPluginResult > > >> >> >resultWithStatus:messageAsString and passes in a file URL, > > >> >>SALocalServer > > >> >> >can get a chance to inspect and modify the result – changing it to > > an > > >> >> >http:localhost URL. It could simply replace the file protocol with > > >> >> >http://localhost:port, then the handler could decode the path > > before > > >> >> >building the response. > > >> >> >This is ugly, but it would prevent the need to change the camera > and > > >> >>file > > >> >> >and should allow other non-cordova plugins that depend on file:// > > URLs > > >> >>to > > >> >> >work. > > >> >> > > > >> >> > > > >> >> >Tony > > >> >> > > > >> >> >On 10/31/14, 2:03 PM, "Homer, Tony" wrote: > > >> >> > > > >> >> >>I started with cookies in my POC, but I was concerned about > replay > > >> >> >>attacks. > > >> >> >>I couldn’t think of a way to avoid replay vulnerability with > > cookies > > >> >> >>(without SSL), so I was going to switch to the side channel > > approach > > >> I > > >> >> >>tried to describe. Do you think replay vulnerability is > > irrelevant? > > >> >>I’m > > >> >> >>not a security guy, so I wasn’t sure if it mattered or not. > That’s > > >> >> >>actually one of the things I was hoping to get feedback about. > > >> >> >> > > >> >> >>I guess I don’t follow how CORS relates to the camera plugin, > does > > it > > >> >>use > > >> >> >>XHR? Maybe you can elaborate? > > >> >> >>I expect I’ll see it when I try the camera plugin from WKWebView, > > >> just > > >> >> >>didn’t get around to it yet. > > >> >> >>The only thing that jumps out at me is that you get a file:// url > > >> >>back - > > >> >> >>we could change that. > > >> >> >>Or maybe intercept file:// requests in the plugin? If it’s just a > > >> >>path > > >> >> >>problem, maybe we could intercept the request, fix the path, then > > >> >>respond > > >> >> >>with the right thing... > > >> >> >> > > >> >> >>Tony > > >> >> >> > > >> >> >>On 10/31/14, 1:19 PM, "Andrew Grieve" > > wrote: > > >> >> >> > > >> >> >>>Unless you're having the server proxy requests to remote sites, > I > > >> >>don't > > >> >> >>>think CORS headers are necessary. > > >> >> >>> >
Re: [iOS 8] WKWebView moving forward
is that now those core plugins effectively support a > > >> >>non-core > > >> >> >plugin. > > >> >> >Also, other (on-cordova) plugins that depend on file protocol will > > be > > >> >> >incompatible with the local web server wkwebview solution (unless > > they > > >> >> >make changes to support it). > > >> >> > > > >> >> >I wonder if it would be better to handle this in CDVPluginResult? > > >> >> >A hook could be added to initWithStatus and exposed to plugins. > > >> >> >Then the SALocalWebServer plugin can use the hook to inspect the > > >> >>message > > >> >> >and fix it, if it is a file:// URL. > > >> >> >So, for example, when camera calls CDVPluginResult > > >> >> >resultWithStatus:messageAsString and passes in a file URL, > > >> >>SALocalServer > > >> >> >can get a chance to inspect and modify the result – changing it to > > an > > >> >> >http:localhost URL. It could simply replace the file protocol with > > >> >> >http://localhost:port, then the handler could decode the path > > before > > >> >> >building the response. > > >> >> >This is ugly, but it would prevent the need to change the camera > and > > >> >>file > > >> >> >and should allow other non-cordova plugins that depend on file:// > > URLs > > >> >>to > > >> >> >work. > > >> >> > > > >> >> > > > >> >> >Tony > > >> >> > > > >> >> >On 10/31/14, 2:03 PM, "Homer, Tony" wrote: > > >> >> > > > >> >> >>I started with cookies in my POC, but I was concerned about > replay > > >> >> >>attacks. > > >> >> >>I couldn’t think of a way to avoid replay vulnerability with > > cookies > > >> >> >>(without SSL), so I was going to switch to the side channel > > approach > > >> I > > >> >> >>tried to describe. Do you think replay vulnerability is > > irrelevant? > > >> >>I’m > > >> >> >>not a security guy, so I wasn’t sure if it mattered or not. > That’s > > >> >> >>actually one of the things I was hoping to get feedback about. > > >> >> >> > > >> >> >>I guess I don’t follow how CORS relates to the camera plugin, > does > > it > > >> >>use > > >> >> >>XHR? Maybe you can elaborate? > > >> >> >>I expect I’ll see it when I try the camera plugin from WKWebView, > > >> just > > >> >> >>didn’t get around to it yet. > > >> >> >>The only thing that jumps out at me is that you get a file:// url > > >> >>back - > > >> >> >>we could change that. > > >> >> >>Or maybe intercept file:// requests in the plugin? If it’s just a > > >> >>path > > >> >> >>problem, maybe we could intercept the request, fix the path, then > > >> >>respond > > >> >> >>with the right thing... > > >> >> >> > > >> >> >>Tony > > >> >> >> > > >> >> >>On 10/31/14, 1:19 PM, "Andrew Grieve" > > wrote: > > >> >> >> > > >> >> >>>Unless you're having the server proxy requests to remote sites, > I > > >> >>don't > > >> >> >>>think CORS headers are necessary. > > >> >> >>> > > >> >> >>>Tony - awesome stuff! absolutely doing it right. More > > >> >>technical-focused > > >> >> >>>discussion the better :). Using cookies seems the best way to me > > >> >>since > > >> >> >>>that > > >> >> >>>covers all requests. Adding headers works only for XHRs. > > >> >> >>> > > >> >> >>>On Fri, Oct 31, 2014 at 12:12 PM, Kirk Shoop (MS OPEN TECH) < > > >> >> >>>kirk.sh...@microsoft.com> wrote: > > >> >> >>> > > >> >> >>>> Yes, the handler
Re: [iOS 8] WKWebView moving forward
n camera calls CDVPluginResult > >> >> >resultWithStatus:messageAsString and passes in a file URL, > >> >>SALocalServer > >> >> >can get a chance to inspect and modify the result – changing it to > an > >> >> >http:localhost URL. It could simply replace the file protocol with > >> >> >http://localhost:port, then the handler could decode the path > before > >> >> >building the response. > >> >> >This is ugly, but it would prevent the need to change the camera and > >> >>file > >> >> >and should allow other non-cordova plugins that depend on file:// > URLs > >> >>to > >> >> >work. > >> >> > > >> >> > > >> >> >Tony > >> >> > > >> >> >On 10/31/14, 2:03 PM, "Homer, Tony" wrote: > >> >> > > >> >> >>I started with cookies in my POC, but I was concerned about replay > >> >> >>attacks. > >> >> >>I couldn’t think of a way to avoid replay vulnerability with > cookies > >> >> >>(without SSL), so I was going to switch to the side channel > approach > >> I > >> >> >>tried to describe. Do you think replay vulnerability is > irrelevant? > >> >>I’m > >> >> >>not a security guy, so I wasn’t sure if it mattered or not. That’s > >> >> >>actually one of the things I was hoping to get feedback about. > >> >> >> > >> >> >>I guess I don’t follow how CORS relates to the camera plugin, does > it > >> >>use > >> >> >>XHR? Maybe you can elaborate? > >> >> >>I expect I’ll see it when I try the camera plugin from WKWebView, > >> just > >> >> >>didn’t get around to it yet. > >> >> >>The only thing that jumps out at me is that you get a file:// url > >> >>back - > >> >> >>we could change that. > >> >> >>Or maybe intercept file:// requests in the plugin? If it’s just a > >> >>path > >> >> >>problem, maybe we could intercept the request, fix the path, then > >> >>respond > >> >> >>with the right thing... > >> >> >> > >> >> >>Tony > >> >> >> > >> >> >>On 10/31/14, 1:19 PM, "Andrew Grieve" > wrote: > >> >> >> > >> >> >>>Unless you're having the server proxy requests to remote sites, I > >> >>don't > >> >> >>>think CORS headers are necessary. > >> >> >>> > >> >> >>>Tony - awesome stuff! absolutely doing it right. More > >> >>technical-focused > >> >> >>>discussion the better :). Using cookies seems the best way to me > >> >>since > >> >> >>>that > >> >> >>>covers all requests. Adding headers works only for XHRs. > >> >> >>> > >> >> >>>On Fri, Oct 31, 2014 at 12:12 PM, Kirk Shoop (MS OPEN TECH) < > >> >> >>>kirk.sh...@microsoft.com> wrote: > >> >> >>> > >> >> >>>> Yes, the handler should be able to add CORS headers to its > >> >>responses > >> >> >>>>that > >> >> >>>> will enable requests from any origin. > >> >> >>>> > >> >> >>>> For instance adding 'Access-Control-Allow-Origin: *' would allow > >> >>any > >> >> >>>> origin to make a request from the local server. > >> >> >>>> > >> >> > http://www.w3.org/TR/cors/#access-control-allow-origin-response-header > >> >> >>>> > >> >> >>>> Similarly Access-Control-Allow-Methods and > >> >> >>>>Access-Control-Allow-Headers > >> >> >>>> could be used to define valid requests. > >> >> >>>> > >> >> >>>> Kirk > >> >> >>>> > >> >> >>>> Developer > >> >> >>>>
Re: [iOS 8] WKWebView moving forward
would prevent the need to change the camera and > >> >>file > >> >> >and should allow other non-cordova plugins that depend on file:// > URLs > >> >>to > >> >> >work. > >> >> > > >> >> > > >> >> >Tony > >> >> > > >> >> >On 10/31/14, 2:03 PM, "Homer, Tony" wrote: > >> >> > > >> >> >>I started with cookies in my POC, but I was concerned about replay > >> >> >>attacks. > >> >> >>I couldn’t think of a way to avoid replay vulnerability with > cookies > >> >> >>(without SSL), so I was going to switch to the side channel > approach > >> I > >> >> >>tried to describe. Do you think replay vulnerability is > irrelevant? > >> >>I’m > >> >> >>not a security guy, so I wasn’t sure if it mattered or not. That’s > >> >> >>actually one of the things I was hoping to get feedback about. > >> >> >> > >> >> >>I guess I don’t follow how CORS relates to the camera plugin, does > it > >> >>use > >> >> >>XHR? Maybe you can elaborate? > >> >> >>I expect I’ll see it when I try the camera plugin from WKWebView, > >> just > >> >> >>didn’t get around to it yet. > >> >> >>The only thing that jumps out at me is that you get a file:// url > >> >>back - > >> >> >>we could change that. > >> >> >>Or maybe intercept file:// requests in the plugin? If it’s just a > >> >>path > >> >> >>problem, maybe we could intercept the request, fix the path, then > >> >>respond > >> >> >>with the right thing... > >> >> >> > >> >> >>Tony > >> >> >> > >> >> >>On 10/31/14, 1:19 PM, "Andrew Grieve" > wrote: > >> >> >> > >> >> >>>Unless you're having the server proxy requests to remote sites, I > >> >>don't > >> >> >>>think CORS headers are necessary. > >> >> >>> > >> >> >>>Tony - awesome stuff! absolutely doing it right. More > >> >>technical-focused > >> >> >>>discussion the better :). Using cookies seems the best way to me > >> >>since > >> >> >>>that > >> >> >>>covers all requests. Adding headers works only for XHRs. > >> >> >>> > >> >> >>>On Fri, Oct 31, 2014 at 12:12 PM, Kirk Shoop (MS OPEN TECH) < > >> >> >>>kirk.sh...@microsoft.com> wrote: > >> >> >>> > >> >> >>>> Yes, the handler should be able to add CORS headers to its > >> >>responses > >> >> >>>>that > >> >> >>>> will enable requests from any origin. > >> >> >>>> > >> >> >>>> For instance adding 'Access-Control-Allow-Origin: *' would allow > >> >>any > >> >> >>>> origin to make a request from the local server. > >> >> >>>> > >> >> > http://www.w3.org/TR/cors/#access-control-allow-origin-response-header > >> >> >>>> > >> >> >>>> Similarly Access-Control-Allow-Methods and > >> >> >>>>Access-Control-Allow-Headers > >> >> >>>> could be used to define valid requests. > >> >> >>>> > >> >> >>>> Kirk > >> >> >>>> > >> >> >>>> Developer > >> >> >>>> Microsoft Open Technologies, Inc. > >> >> >>>> > >> >> >>>> -Original Message- > >> >> >>>> From: Homer, Tony [mailto:tony.ho...@intel.com] > >> >> >>>> Sent: Friday, October 31, 2014 8:40 AM > >> >> >>>> To: dev@cordova.apache.org > >> >> >>>> Subject: Re: [iOS 8] WKWebView moving forward > >> >> >>>> > >> >> >>>> Last night I added a handler to the Local Web Server plugin that > >> >> >>>>returns > >> >> >>>> 403 for non-localhost r
Re: [iOS 8] WKWebView moving forward
he camera plugin, does it >> >>use >> >> >>XHR? Maybe you can elaborate? >> >> >>I expect I’ll see it when I try the camera plugin from WKWebView, >> just >> >> >>didn’t get around to it yet. >> >> >>The only thing that jumps out at me is that you get a file:// url >> >>back - >> >> >>we could change that. >> >> >>Or maybe intercept file:// requests in the plugin? If it’s just a >> >>path >> >> >>problem, maybe we could intercept the request, fix the path, then >> >>respond >> >> >>with the right thing... >> >> >> >> >> >>Tony >> >> >> >> >> >>On 10/31/14, 1:19 PM, "Andrew Grieve" wrote: >> >> >> >> >> >>>Unless you're having the server proxy requests to remote sites, I >> >>don't >> >> >>>think CORS headers are necessary. >> >> >>> >> >> >>>Tony - awesome stuff! absolutely doing it right. More >> >>technical-focused >> >> >>>discussion the better :). Using cookies seems the best way to me >> >>since >> >> >>>that >> >> >>>covers all requests. Adding headers works only for XHRs. >> >> >>> >> >> >>>On Fri, Oct 31, 2014 at 12:12 PM, Kirk Shoop (MS OPEN TECH) < >> >> >>>kirk.sh...@microsoft.com> wrote: >> >> >>> >> >> >>>> Yes, the handler should be able to add CORS headers to its >> >>responses >> >> >>>>that >> >> >>>> will enable requests from any origin. >> >> >>>> >> >> >>>> For instance adding 'Access-Control-Allow-Origin: *' would allow >> >>any >> >> >>>> origin to make a request from the local server. >> >> >>>> >> >> http://www.w3.org/TR/cors/#access-control-allow-origin-response-header >> >> >>>> >> >> >>>> Similarly Access-Control-Allow-Methods and >> >> >>>>Access-Control-Allow-Headers >> >> >>>> could be used to define valid requests. >> >> >>>> >> >> >>>> Kirk >> >> >>>> >> >> >>>> Developer >> >> >>>> Microsoft Open Technologies, Inc. >> >> >>>> >> >> >>>> -Original Message- >> >> >>>> From: Homer, Tony [mailto:tony.ho...@intel.com] >> >> >>>> Sent: Friday, October 31, 2014 8:40 AM >> >> >>>> To: dev@cordova.apache.org >> >> >>>> Subject: Re: [iOS 8] WKWebView moving forward >> >> >>>> >> >> >>>> Last night I added a handler to the Local Web Server plugin that >> >> >>>>returns >> >> >>>> 403 for non-localhost requests. >> >> >>>> The handler also has a prototype token system to restrict requests >> >>to >> >> >>>>the >> >> >>>> app, but I need to change the approach a bit. >> >> >>>> Currently I set a cookie and the handler just checks for the >> cookie >> >> >>>>and >> >> >>>> returns 403 if it is missing. >> >> >>>> This is susceptible to replay attacks from backgrounded apps - not >> >> >>>>sure >> >> >>>>if >> >> >>>> that is important or not. >> >> >>>> >> >> >>>> I¹m going to investigate adding a map to the plugin, then add an >> >>entry >> >> >>>>for >> >> >>>> every request. >> >> >>>> The entry will be a hash of the request and a random number. >> >> >>>> >> >> >>>> I¹ll have to wire up support for overriding url loads so that I >> can >> >> >>>>add >> >> >>>> the header with the random number to the request. >> >> >>>> Then the request handler will look the entry up in the map and >> >>remove >> >> >>>>it - >> >> >>>> this should eliminate re-playability. >> >> >>>
Re: [iOS 8] WKWebView moving forward
ostile wifi network” case, we need something like > >> SSL. > >> > >> On 11/1/14, 4:28 PM, "Homer, Tony" wrote: > >> > >> >I started looking at how to make the camera plugin be able to work in > >> >WKWebView. > >> >Before, I had mentioned intercepting resource requests as a way to fix > >>the > >> >file:// requests. > >> >However, WKWebView does not offer a way to intercept resource requests > >>so > >> >that won’t work. > >> >:/ > >> > > >> >Andrew had suggested introducing some proxy paths as a way to deal with > >> >the path problems, which seems fine. > >> >On the other hand, the request handlers could just inspect the path in > >>the > >> >request and do the right thing - are the proxy paths needed? > >> >I think implicit in those comments was a suggestion that the affected > >> >plugins such as camera could return URLs using those paths. > >> >The thing about changing camera and file plugins to support localhost > >>that > >> >bothers me, is that now those core plugins effectively support a > >>non-core > >> >plugin. > >> >Also, other (on-cordova) plugins that depend on file protocol will be > >> >incompatible with the local web server wkwebview solution (unless they > >> >make changes to support it). > >> > > >> >I wonder if it would be better to handle this in CDVPluginResult? > >> >A hook could be added to initWithStatus and exposed to plugins. > >> >Then the SALocalWebServer plugin can use the hook to inspect the > >>message > >> >and fix it, if it is a file:// URL. > >> >So, for example, when camera calls CDVPluginResult > >> >resultWithStatus:messageAsString and passes in a file URL, > >>SALocalServer > >> >can get a chance to inspect and modify the result – changing it to an > >> >http:localhost URL. It could simply replace the file protocol with > >> >http://localhost:port, then the handler could decode the path before > >> >building the response. > >> >This is ugly, but it would prevent the need to change the camera and > >>file > >> >and should allow other non-cordova plugins that depend on file:// URLs > >>to > >> >work. > >> > > >> > > >> >Tony > >> > > >> >On 10/31/14, 2:03 PM, "Homer, Tony" wrote: > >> > > >> >>I started with cookies in my POC, but I was concerned about replay > >> >>attacks. > >> >>I couldn’t think of a way to avoid replay vulnerability with cookies > >> >>(without SSL), so I was going to switch to the side channel approach I > >> >>tried to describe. Do you think replay vulnerability is irrelevant? > >>I’m > >> >>not a security guy, so I wasn’t sure if it mattered or not. That’s > >> >>actually one of the things I was hoping to get feedback about. > >> >> > >> >>I guess I don’t follow how CORS relates to the camera plugin, does it > >>use > >> >>XHR? Maybe you can elaborate? > >> >>I expect I’ll see it when I try the camera plugin from WKWebView, just > >> >>didn’t get around to it yet. > >> >>The only thing that jumps out at me is that you get a file:// url > >>back - > >> >>we could change that. > >> >>Or maybe intercept file:// requests in the plugin? If it’s just a > >>path > >> >>problem, maybe we could intercept the request, fix the path, then > >>respond > >> >>with the right thing... > >> >> > >> >>Tony > >> >> > >> >>On 10/31/14, 1:19 PM, "Andrew Grieve" wrote: > >> >> > >> >>>Unless you're having the server proxy requests to remote sites, I > >>don't > >> >>>think CORS headers are necessary. > >> >>> > >> >>>Tony - awesome stuff! absolutely doing it right. More > >>technical-focused > >> >>>discussion the better :). Using cookies seems the best way to me > >>since > >> >>>that > >> >>>covers all requests. Adding headers works only for XHRs. > >> >>> > >> >>>On Fri, Oct 31, 2014 at 12:12 PM, Kirk Shoop (MS OPEN TECH) < > >> >>>kirk.sh...@microsoft.com>
Re: [iOS 8] WKWebView moving forward
on-cordova) plugins that depend on file protocol will be >> >incompatible with the local web server wkwebview solution (unless they >> >make changes to support it). >> > >> >I wonder if it would be better to handle this in CDVPluginResult? >> >A hook could be added to initWithStatus and exposed to plugins. >> >Then the SALocalWebServer plugin can use the hook to inspect the >>message >> >and fix it, if it is a file:// URL. >> >So, for example, when camera calls CDVPluginResult >> >resultWithStatus:messageAsString and passes in a file URL, >>SALocalServer >> >can get a chance to inspect and modify the result – changing it to an >> >http:localhost URL. It could simply replace the file protocol with >> >http://localhost:port, then the handler could decode the path before >> >building the response. >> >This is ugly, but it would prevent the need to change the camera and >>file >> >and should allow other non-cordova plugins that depend on file:// URLs >>to >> >work. >> > >> > >> >Tony >> > >> >On 10/31/14, 2:03 PM, "Homer, Tony" wrote: >> > >> >>I started with cookies in my POC, but I was concerned about replay >> >>attacks. >> >>I couldn’t think of a way to avoid replay vulnerability with cookies >> >>(without SSL), so I was going to switch to the side channel approach I >> >>tried to describe. Do you think replay vulnerability is irrelevant? >>I’m >> >>not a security guy, so I wasn’t sure if it mattered or not. That’s >> >>actually one of the things I was hoping to get feedback about. >> >> >> >>I guess I don’t follow how CORS relates to the camera plugin, does it >>use >> >>XHR? Maybe you can elaborate? >> >>I expect I’ll see it when I try the camera plugin from WKWebView, just >> >>didn’t get around to it yet. >> >>The only thing that jumps out at me is that you get a file:// url >>back - >> >>we could change that. >> >>Or maybe intercept file:// requests in the plugin? If it’s just a >>path >> >>problem, maybe we could intercept the request, fix the path, then >>respond >> >>with the right thing... >> >> >> >>Tony >> >> >> >>On 10/31/14, 1:19 PM, "Andrew Grieve" wrote: >> >> >> >>>Unless you're having the server proxy requests to remote sites, I >>don't >> >>>think CORS headers are necessary. >> >>> >> >>>Tony - awesome stuff! absolutely doing it right. More >>technical-focused >> >>>discussion the better :). Using cookies seems the best way to me >>since >> >>>that >> >>>covers all requests. Adding headers works only for XHRs. >> >>> >> >>>On Fri, Oct 31, 2014 at 12:12 PM, Kirk Shoop (MS OPEN TECH) < >> >>>kirk.sh...@microsoft.com> wrote: >> >>> >> >>>> Yes, the handler should be able to add CORS headers to its >>responses >> >>>>that >> >>>> will enable requests from any origin. >> >>>> >> >>>> For instance adding 'Access-Control-Allow-Origin: *' would allow >>any >> >>>> origin to make a request from the local server. >> >>>> >> http://www.w3.org/TR/cors/#access-control-allow-origin-response-header >> >>>> >> >>>> Similarly Access-Control-Allow-Methods and >> >>>>Access-Control-Allow-Headers >> >>>> could be used to define valid requests. >> >>>> >> >>>> Kirk >> >>>> >> >>>> Developer >> >>>> Microsoft Open Technologies, Inc. >> >>>> >> >>>> -Original Message- >> >>>> From: Homer, Tony [mailto:tony.ho...@intel.com] >> >>>> Sent: Friday, October 31, 2014 8:40 AM >> >>>> To: dev@cordova.apache.org >> >>>> Subject: Re: [iOS 8] WKWebView moving forward >> >>>> >> >>>> Last night I added a handler to the Local Web Server plugin that >> >>>>returns >> >>>> 403 for non-localhost requests. >> >>>> The handler also has a prototype token system to restrict requests >>to >> >>>>the >> >>>> app, but I need to change
Re: [iOS 8] WKWebView moving forward
ote: > > > >>I started with cookies in my POC, but I was concerned about replay > >>attacks. > >>I couldn’t think of a way to avoid replay vulnerability with cookies > >>(without SSL), so I was going to switch to the side channel approach I > >>tried to describe. Do you think replay vulnerability is irrelevant? I’m > >>not a security guy, so I wasn’t sure if it mattered or not. That’s > >>actually one of the things I was hoping to get feedback about. > >> > >>I guess I don’t follow how CORS relates to the camera plugin, does it use > >>XHR? Maybe you can elaborate? > >>I expect I’ll see it when I try the camera plugin from WKWebView, just > >>didn’t get around to it yet. > >>The only thing that jumps out at me is that you get a file:// url back - > >>we could change that. > >>Or maybe intercept file:// requests in the plugin? If it’s just a path > >>problem, maybe we could intercept the request, fix the path, then respond > >>with the right thing... > >> > >>Tony > >> > >>On 10/31/14, 1:19 PM, "Andrew Grieve" wrote: > >> > >>>Unless you're having the server proxy requests to remote sites, I don't > >>>think CORS headers are necessary. > >>> > >>>Tony - awesome stuff! absolutely doing it right. More technical-focused > >>>discussion the better :). Using cookies seems the best way to me since > >>>that > >>>covers all requests. Adding headers works only for XHRs. > >>> > >>>On Fri, Oct 31, 2014 at 12:12 PM, Kirk Shoop (MS OPEN TECH) < > >>>kirk.sh...@microsoft.com> wrote: > >>> > >>>> Yes, the handler should be able to add CORS headers to its responses > >>>>that > >>>> will enable requests from any origin. > >>>> > >>>> For instance adding 'Access-Control-Allow-Origin: *' would allow any > >>>> origin to make a request from the local server. > >>>> > http://www.w3.org/TR/cors/#access-control-allow-origin-response-header > >>>> > >>>> Similarly Access-Control-Allow-Methods and > >>>>Access-Control-Allow-Headers > >>>> could be used to define valid requests. > >>>> > >>>> Kirk > >>>> > >>>> Developer > >>>> Microsoft Open Technologies, Inc. > >>>> > >>>> -Original Message- > >>>> From: Homer, Tony [mailto:tony.ho...@intel.com] > >>>> Sent: Friday, October 31, 2014 8:40 AM > >>>> To: dev@cordova.apache.org > >>>> Subject: Re: [iOS 8] WKWebView moving forward > >>>> > >>>> Last night I added a handler to the Local Web Server plugin that > >>>>returns > >>>> 403 for non-localhost requests. > >>>> The handler also has a prototype token system to restrict requests to > >>>>the > >>>> app, but I need to change the approach a bit. > >>>> Currently I set a cookie and the handler just checks for the cookie > >>>>and > >>>> returns 403 if it is missing. > >>>> This is susceptible to replay attacks from backgrounded apps - not > >>>>sure > >>>>if > >>>> that is important or not. > >>>> > >>>> I¹m going to investigate adding a map to the plugin, then add an entry > >>>>for > >>>> every request. > >>>> The entry will be a hash of the request and a random number. > >>>> > >>>> I¹ll have to wire up support for overriding url loads so that I can > >>>>add > >>>> the header with the random number to the request. > >>>> Then the request handler will look the entry up in the map and remove > >>>>it - > >>>> this should eliminate re-playability. > >>>> > >>>> I¹m not sure about the CORS issue with camera pluginŠ I¹ll be curious > >>>>to > >>>> test it - maybe it could be addressed by modifying the response in the > >>>> GCDWebServer handler? > >>>> > >>>> Tony > >>>> > >>>> P.S. This is my first attempt participating in discussion on the list > >>>>- > >>>> let me know if I¹m doing it wrong! > >>>> Am I wasting my time investigating this? Should I just leave it > >
Re: [iOS 8] WKWebView moving forward
url back - > >>we could change that. > >>Or maybe intercept file:// requests in the plugin? If it’s just a path > >>problem, maybe we could intercept the request, fix the path, then respond > >>with the right thing... > >> > >>Tony > >> > >>On 10/31/14, 1:19 PM, "Andrew Grieve" wrote: > >> > >>>Unless you're having the server proxy requests to remote sites, I don't > >>>think CORS headers are necessary. > >>> > >>>Tony - awesome stuff! absolutely doing it right. More technical-focused > >>>discussion the better :). Using cookies seems the best way to me since > >>>that > >>>covers all requests. Adding headers works only for XHRs. > >>> > >>>On Fri, Oct 31, 2014 at 12:12 PM, Kirk Shoop (MS OPEN TECH) < > >>>kirk.sh...@microsoft.com> wrote: > >>> > >>>> Yes, the handler should be able to add CORS headers to its responses > >>>>that > >>>> will enable requests from any origin. > >>>> > >>>> For instance adding 'Access-Control-Allow-Origin: *' would allow any > >>>> origin to make a request from the local server. > >>>> > http://www.w3.org/TR/cors/#access-control-allow-origin-response-header > >>>> > >>>> Similarly Access-Control-Allow-Methods and > >>>>Access-Control-Allow-Headers > >>>> could be used to define valid requests. > >>>> > >>>> Kirk > >>>> > >>>> Developer > >>>> Microsoft Open Technologies, Inc. > >>>> > >>>> -Original Message- > >>>> From: Homer, Tony [mailto:tony.ho...@intel.com] > >>>> Sent: Friday, October 31, 2014 8:40 AM > >>>> To: dev@cordova.apache.org > >>>> Subject: Re: [iOS 8] WKWebView moving forward > >>>> > >>>> Last night I added a handler to the Local Web Server plugin that > >>>>returns > >>>> 403 for non-localhost requests. > >>>> The handler also has a prototype token system to restrict requests to > >>>>the > >>>> app, but I need to change the approach a bit. > >>>> Currently I set a cookie and the handler just checks for the cookie > >>>>and > >>>> returns 403 if it is missing. > >>>> This is susceptible to replay attacks from backgrounded apps - not > >>>>sure > >>>>if > >>>> that is important or not. > >>>> > >>>> I¹m going to investigate adding a map to the plugin, then add an entry > >>>>for > >>>> every request. > >>>> The entry will be a hash of the request and a random number. > >>>> > >>>> I¹ll have to wire up support for overriding url loads so that I can > >>>>add > >>>> the header with the random number to the request. > >>>> Then the request handler will look the entry up in the map and remove > >>>>it - > >>>> this should eliminate re-playability. > >>>> > >>>> I¹m not sure about the CORS issue with camera pluginŠ I¹ll be curious > >>>>to > >>>> test it - maybe it could be addressed by modifying the response in the > >>>> GCDWebServer handler? > >>>> > >>>> Tony > >>>> > >>>> P.S. This is my first attempt participating in discussion on the list > >>>>- > >>>> let me know if I¹m doing it wrong! > >>>> Am I wasting my time investigating this? Should I just leave it > >>>>Shazron? > >>>> > >>>> On 10/30/14, 9:52 PM, "Andrew Grieve" wrote: > >>>> > >>>> >On Thu, Oct 30, 2014 at 5:05 PM, Shazron 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 > >>>> >
Re: [iOS 8] WKWebView moving forward
-focused >>>discussion the better :). Using cookies seems the best way to me since >>>that >>>covers all requests. Adding headers works only for XHRs. >>> >>>On Fri, Oct 31, 2014 at 12:12 PM, Kirk Shoop (MS OPEN TECH) < >>>kirk.sh...@microsoft.com> wrote: >>> >>>> Yes, the handler should be able to add CORS headers to its responses >>>>that >>>> will enable requests from any origin. >>>> >>>> For instance adding 'Access-Control-Allow-Origin: *' would allow any >>>> origin to make a request from the local server. >>>> http://www.w3.org/TR/cors/#access-control-allow-origin-response-header >>>> >>>> Similarly Access-Control-Allow-Methods and >>>>Access-Control-Allow-Headers >>>> could be used to define valid requests. >>>> >>>> Kirk >>>> >>>> Developer >>>> Microsoft Open Technologies, Inc. >>>> >>>> -Original Message- >>>> From: Homer, Tony [mailto:tony.ho...@intel.com] >>>> Sent: Friday, October 31, 2014 8:40 AM >>>> To: dev@cordova.apache.org >>>> Subject: Re: [iOS 8] WKWebView moving forward >>>> >>>> Last night I added a handler to the Local Web Server plugin that >>>>returns >>>> 403 for non-localhost requests. >>>> The handler also has a prototype token system to restrict requests to >>>>the >>>> app, but I need to change the approach a bit. >>>> Currently I set a cookie and the handler just checks for the cookie >>>>and >>>> returns 403 if it is missing. >>>> This is susceptible to replay attacks from backgrounded apps - not >>>>sure >>>>if >>>> that is important or not. >>>> >>>> I¹m going to investigate adding a map to the plugin, then add an entry >>>>for >>>> every request. >>>> The entry will be a hash of the request and a random number. >>>> >>>> I¹ll have to wire up support for overriding url loads so that I can >>>>add >>>> the header with the random number to the request. >>>> Then the request handler will look the entry up in the map and remove >>>>it - >>>> this should eliminate re-playability. >>>> >>>> I¹m not sure about the CORS issue with camera pluginŠ I¹ll be curious >>>>to >>>> test it - maybe it could be addressed by modifying the response in the >>>> GCDWebServer handler? >>>> >>>> Tony >>>> >>>> P.S. This is my first attempt participating in discussion on the list >>>>- >>>> let me know if I¹m doing it wrong! >>>> Am I wasting my time investigating this? Should I just leave it >>>>Shazron? >>>> >>>> On 10/30/14, 9:52 PM, "Andrew Grieve" wrote: >>>> >>>> >On Thu, Oct 30, 2014 at 5:05 PM, Shazron 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 >>>
Re: [iOS 8] WKWebView moving forward
I started looking at how to make the camera plugin be able to work in WKWebView. Before, I had mentioned intercepting resource requests as a way to fix the file:// requests. However, WKWebView does not offer a way to intercept resource requests so that won’t work. :/ Andrew had suggested introducing some proxy paths as a way to deal with the path problems, which seems fine. On the other hand, the request handlers could just inspect the path in the request and do the right thing - are the proxy paths needed? I think implicit in those comments was a suggestion that the affected plugins such as camera could return URLs using those paths. The thing about changing camera and file plugins to support localhost that bothers me, is that now those core plugins effectively support a non-core plugin. Also, other (on-cordova) plugins that depend on file protocol will be incompatible with the local web server wkwebview solution (unless they make changes to support it). I wonder if it would be better to handle this in CDVPluginResult? A hook could be added to initWithStatus and exposed to plugins. Then the SALocalWebServer plugin can use the hook to inspect the message and fix it, if it is a file:// URL. So, for example, when camera calls CDVPluginResult resultWithStatus:messageAsString and passes in a file URL, SALocalServer can get a chance to inspect and modify the result – changing it to an http:localhost URL. It could simply replace the file protocol with http://localhost:port, then the handler could decode the path before building the response. This is ugly, but it would prevent the need to change the camera and file and should allow other non-cordova plugins that depend on file:// URLs to work. Tony On 10/31/14, 2:03 PM, "Homer, Tony" wrote: >I started with cookies in my POC, but I was concerned about replay >attacks. >I couldn’t think of a way to avoid replay vulnerability with cookies >(without SSL), so I was going to switch to the side channel approach I >tried to describe. Do you think replay vulnerability is irrelevant? I’m >not a security guy, so I wasn’t sure if it mattered or not. That’s >actually one of the things I was hoping to get feedback about. > >I guess I don’t follow how CORS relates to the camera plugin, does it use >XHR? Maybe you can elaborate? >I expect I’ll see it when I try the camera plugin from WKWebView, just >didn’t get around to it yet. >The only thing that jumps out at me is that you get a file:// url back - >we could change that. >Or maybe intercept file:// requests in the plugin? If it’s just a path >problem, maybe we could intercept the request, fix the path, then respond >with the right thing... > >Tony > >On 10/31/14, 1:19 PM, "Andrew Grieve" wrote: > >>Unless you're having the server proxy requests to remote sites, I don't >>think CORS headers are necessary. >> >>Tony - awesome stuff! absolutely doing it right. More technical-focused >>discussion the better :). Using cookies seems the best way to me since >>that >>covers all requests. Adding headers works only for XHRs. >> >>On Fri, Oct 31, 2014 at 12:12 PM, Kirk Shoop (MS OPEN TECH) < >>kirk.sh...@microsoft.com> wrote: >> >>> Yes, the handler should be able to add CORS headers to its responses >>>that >>> will enable requests from any origin. >>> >>> For instance adding 'Access-Control-Allow-Origin: *' would allow any >>> origin to make a request from the local server. >>> http://www.w3.org/TR/cors/#access-control-allow-origin-response-header >>> >>> Similarly Access-Control-Allow-Methods and Access-Control-Allow-Headers >>> could be used to define valid requests. >>> >>> Kirk >>> >>> Developer >>> Microsoft Open Technologies, Inc. >>> >>> -Original Message- >>> From: Homer, Tony [mailto:tony.ho...@intel.com] >>> Sent: Friday, October 31, 2014 8:40 AM >>> To: dev@cordova.apache.org >>> Subject: Re: [iOS 8] WKWebView moving forward >>> >>> Last night I added a handler to the Local Web Server plugin that >>>returns >>> 403 for non-localhost requests. >>> The handler also has a prototype token system to restrict requests to >>>the >>> app, but I need to change the approach a bit. >>> Currently I set a cookie and the handler just checks for the cookie and >>> returns 403 if it is missing. >>> This is susceptible to replay attacks from backgrounded apps - not sure >>>if >>> that is important or not. >>> >>> I¹m going to investigate adding a map to the plugin, then add an entry >>>for >>> every request. >>&
Re: [iOS 8] WKWebView moving forward
I started with cookies in my POC, but I was concerned about replay attacks. I couldn’t think of a way to avoid replay vulnerability with cookies (without SSL), so I was going to switch to the side channel approach I tried to describe. Do you think replay vulnerability is irrelevant? I’m not a security guy, so I wasn’t sure if it mattered or not. That’s actually one of the things I was hoping to get feedback about. I guess I don’t follow how CORS relates to the camera plugin, does it use XHR? Maybe you can elaborate? I expect I’ll see it when I try the camera plugin from WKWebView, just didn’t get around to it yet. The only thing that jumps out at me is that you get a file:// url back - we could change that. Or maybe intercept file:// requests in the plugin? If it’s just a path problem, maybe we could intercept the request, fix the path, then respond with the right thing... Tony On 10/31/14, 1:19 PM, "Andrew Grieve" wrote: >Unless you're having the server proxy requests to remote sites, I don't >think CORS headers are necessary. > >Tony - awesome stuff! absolutely doing it right. More technical-focused >discussion the better :). Using cookies seems the best way to me since >that >covers all requests. Adding headers works only for XHRs. > >On Fri, Oct 31, 2014 at 12:12 PM, Kirk Shoop (MS OPEN TECH) < >kirk.sh...@microsoft.com> wrote: > >> Yes, the handler should be able to add CORS headers to its responses >>that >> will enable requests from any origin. >> >> For instance adding 'Access-Control-Allow-Origin: *' would allow any >> origin to make a request from the local server. >> http://www.w3.org/TR/cors/#access-control-allow-origin-response-header >> >> Similarly Access-Control-Allow-Methods and Access-Control-Allow-Headers >> could be used to define valid requests. >> >> Kirk >> >> Developer >> Microsoft Open Technologies, Inc. >> >> -----Original Message- >> From: Homer, Tony [mailto:tony.ho...@intel.com] >> Sent: Friday, October 31, 2014 8:40 AM >> To: dev@cordova.apache.org >> Subject: Re: [iOS 8] WKWebView moving forward >> >> Last night I added a handler to the Local Web Server plugin that returns >> 403 for non-localhost requests. >> The handler also has a prototype token system to restrict requests to >>the >> app, but I need to change the approach a bit. >> Currently I set a cookie and the handler just checks for the cookie and >> returns 403 if it is missing. >> This is susceptible to replay attacks from backgrounded apps - not sure >>if >> that is important or not. >> >> I¹m going to investigate adding a map to the plugin, then add an entry >>for >> every request. >> The entry will be a hash of the request and a random number. >> >> I¹ll have to wire up support for overriding url loads so that I can add >> the header with the random number to the request. >> Then the request handler will look the entry up in the map and remove >>it - >> this should eliminate re-playability. >> >> I¹m not sure about the CORS issue with camera pluginŠ I¹ll be curious to >> test it - maybe it could be addressed by modifying the response in the >> GCDWebServer handler? >> >> Tony >> >> P.S. This is my first attempt participating in discussion on the list - >> let me know if I¹m doing it wrong! >> Am I wasting my time investigating this? Should I just leave it >>Shazron? >> >> On 10/30/14, 9:52 PM, "Andrew Grieve" wrote: >> >> >On Thu, Oct 30, 2014 at 5:05 PM, Shazron 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
Re: [iOS 8] WKWebView moving forward
Unless you're having the server proxy requests to remote sites, I don't think CORS headers are necessary. Tony - awesome stuff! absolutely doing it right. More technical-focused discussion the better :). Using cookies seems the best way to me since that covers all requests. Adding headers works only for XHRs. On Fri, Oct 31, 2014 at 12:12 PM, Kirk Shoop (MS OPEN TECH) < kirk.sh...@microsoft.com> wrote: > Yes, the handler should be able to add CORS headers to its responses that > will enable requests from any origin. > > For instance adding 'Access-Control-Allow-Origin: *' would allow any > origin to make a request from the local server. > http://www.w3.org/TR/cors/#access-control-allow-origin-response-header > > Similarly Access-Control-Allow-Methods and Access-Control-Allow-Headers > could be used to define valid requests. > > Kirk > > Developer > Microsoft Open Technologies, Inc. > > -Original Message- > From: Homer, Tony [mailto:tony.ho...@intel.com] > Sent: Friday, October 31, 2014 8:40 AM > To: dev@cordova.apache.org > Subject: Re: [iOS 8] WKWebView moving forward > > Last night I added a handler to the Local Web Server plugin that returns > 403 for non-localhost requests. > The handler also has a prototype token system to restrict requests to the > app, but I need to change the approach a bit. > Currently I set a cookie and the handler just checks for the cookie and > returns 403 if it is missing. > This is susceptible to replay attacks from backgrounded apps - not sure if > that is important or not. > > I¹m going to investigate adding a map to the plugin, then add an entry for > every request. > The entry will be a hash of the request and a random number. > > I¹ll have to wire up support for overriding url loads so that I can add > the header with the random number to the request. > Then the request handler will look the entry up in the map and remove it - > this should eliminate re-playability. > > I¹m not sure about the CORS issue with camera pluginŠ I¹ll be curious to > test it - maybe it could be addressed by modifying the response in the > GCDWebServer handler? > > Tony > > P.S. This is my first attempt participating in discussion on the list - > let me know if I¹m doing it wrong! > Am I wasting my time investigating this? Should I just leave it Shazron? > > On 10/30/14, 9:52 PM, "Andrew Grieve" wrote: > > >On Thu, Oct 30, 2014 at 5:05 PM, Shazron 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 > >> 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 ). > >> > > >> > Although we might just do (this is different than the current mapping > >>in > >> > the plugin): > >> > http://l
RE: [iOS 8] WKWebView moving forward
Yes, the handler should be able to add CORS headers to its responses that will enable requests from any origin. For instance adding 'Access-Control-Allow-Origin: *' would allow any origin to make a request from the local server. http://www.w3.org/TR/cors/#access-control-allow-origin-response-header Similarly Access-Control-Allow-Methods and Access-Control-Allow-Headers could be used to define valid requests. Kirk Developer Microsoft Open Technologies, Inc. -Original Message- From: Homer, Tony [mailto:tony.ho...@intel.com] Sent: Friday, October 31, 2014 8:40 AM To: dev@cordova.apache.org Subject: Re: [iOS 8] WKWebView moving forward Last night I added a handler to the Local Web Server plugin that returns 403 for non-localhost requests. The handler also has a prototype token system to restrict requests to the app, but I need to change the approach a bit. Currently I set a cookie and the handler just checks for the cookie and returns 403 if it is missing. This is susceptible to replay attacks from backgrounded apps - not sure if that is important or not. I¹m going to investigate adding a map to the plugin, then add an entry for every request. The entry will be a hash of the request and a random number. I¹ll have to wire up support for overriding url loads so that I can add the header with the random number to the request. Then the request handler will look the entry up in the map and remove it - this should eliminate re-playability. I¹m not sure about the CORS issue with camera pluginŠ I¹ll be curious to test it - maybe it could be addressed by modifying the response in the GCDWebServer handler? Tony P.S. This is my first attempt participating in discussion on the list - let me know if I¹m doing it wrong! Am I wasting my time investigating this? Should I just leave it Shazron? On 10/30/14, 9:52 PM, "Andrew Grieve" wrote: >On Thu, Oct 30, 2014 at 5:05 PM, Shazron 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 >> 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 ). >> > >> > 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 wrote: >> > >> > > This does not preclude using the file url API function I suppose. >>
Re: [iOS 8] WKWebView moving forward
Last night I added a handler to the Local Web Server plugin that returns 403 for non-localhost requests. The handler also has a prototype token system to restrict requests to the app, but I need to change the approach a bit. Currently I set a cookie and the handler just checks for the cookie and returns 403 if it is missing. This is susceptible to replay attacks from backgrounded apps - not sure if that is important or not. I¹m going to investigate adding a map to the plugin, then add an entry for every request. The entry will be a hash of the request and a random number. I¹ll have to wire up support for overriding url loads so that I can add the header with the random number to the request. Then the request handler will look the entry up in the map and remove it - this should eliminate re-playability. I¹m not sure about the CORS issue with camera pluginŠ I¹ll be curious to test it - maybe it could be addressed by modifying the response in the GCDWebServer handler? Tony P.S. This is my first attempt participating in discussion on the list - let me know if I¹m doing it wrong! Am I wasting my time investigating this? Should I just leave it Shazron? On 10/30/14, 9:52 PM, "Andrew Grieve" wrote: >On Thu, Oct 30, 2014 at 5:05 PM, Shazron 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 >> 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 ). >> > >> > 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 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 >> > > 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" 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, wha
Re: [iOS 8] WKWebView moving forward
On Thu, Oct 30, 2014 at 5:05 PM, Shazron 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 > 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 ). > > > > 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 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 > > > 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" 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 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
Re: [iOS 8] WKWebView moving forward
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 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 ). > > 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 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 > > 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" 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 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
Re: [iOS 8] WKWebView moving forward
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 ). 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 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 > 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" 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 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) > > > > > >
Re: [iOS 8] WKWebView moving forward
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 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" 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 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) > > >
Re: [iOS 8] WKWebView moving forward
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" 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 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) >
