both ios@4 and cordova-plugin-wkwebviewengine need 1 more vote. Someone step up so Shaz can wrap up the vote threads and publish these!
On Fri, Dec 4, 2015 at 2:07 PM, Carlos Santana <csantan...@gmail.com> wrote: > +1 > > On Fri, Dec 4, 2015 at 3:07 PM Shazron <shaz...@gmail.com> wrote: > > > After working out some bridge improvements and fixing some Platform > > API bugs and testing, I believe it's ready. I'll start a [VOTE] thread > > soon. > > > > On Thu, Dec 3, 2015 at 5:19 PM, Carlos Santana <csantan...@gmail.com> > > wrote: > > > +1 let's move forward this items with WKWebview I don't see holding up > > the > > > platform. > > > > > > Don't see any changes going on the platform, if any they will go into > the > > > pluggable webview plugin or creating new plugin to handle. > > > On Wed, Dec 2, 2015 at 8:40 PM Shazron <shaz...@gmail.com> wrote: > > > > > >> Regarding Platform API, Vladimir Kotikov and Sergey Grebnov agree in > > >> the PR comments that the changes can go in to cordova-ios-4.x: > > >> https://github.com/apache/cordova-ios/pull/176 > > >> > > >> On Wed, Dec 2, 2015 at 5:38 PM, Shazron <shaz...@gmail.com> wrote: > > >> > Also, check footnote 3 above. > > >> > > > >> > Yes, WebKit defines window.openDatabase but it doesn't do anything. > > >> > Not sure why their tests didn't catch this... (see footnote for the > > >> > bug) > > >> > > > >> > With CSP off to rule things out: > > >> > XHR to yourself of course works, but doesn't really make sense for > > >> > real-world use. XHR to a sibling file, parent file, or any child > file > > >> > results in the error ""Cross origin requests are only supported for > > >> > HTTP”. > > >> > > > >> > To illustrate: > > >> > > > >> > | > > >> > parent.xml > > >> > | > > >> > www > > >> > |---- index.html (file currently loaded) > > >> > |---- sibling.xml > > >> > |---- child-folder > > >> > | |---- child.xml > > >> > > > >> > index.html is the currently loaded file in the WebView. From it, you > > >> > can't load parent.xml, sibling.xml nor child.xml using XHR according > > >> > to my tests. > > >> > > > >> > Regarding *why* we have these storage tests, that is out of scope > for > > >> > this discussion, but I agree. > > >> > > > >> > > > >> > On Wed, Dec 2, 2015 at 6:37 AM, Carlos Santana < > csantan...@gmail.com> > > >> wrote: > > >> >> I'm guessing "pending" is the same as skipping the test. > > >> >> I'm guessing WKWebView doesn't support Web SQL, but > > window.openDatabase > > >> >> exist but it doesn't do anything? > > >> >> I ask because I only saw the pending for wkwebview spec.18 for > using > > it, > > >> >> not for spec.9 where it checks that exists. > > >> >> Anyway after all questions, why the we are still testing for > storage > > >> APIs? > > >> >> Cordova doesn't supported code to provide this storage APIs. > > >> >> I think we should remove the storage tests all together, this is > > >> >> webview/browser testing space. > > >> >> > > >> >> As for local xhr, is the problem only with specifying "../" > relative > > >> path > > >> >> in the xhr url and not local resources? > > >> >> I see that doing xhr "index.html" that's a local resource and it > > works, > > >> and > > >> >> also "./" also passes. > > >> >> Aren't all this relative paths transform into full urls, and they > > will > > >> have > > >> >> file:// in the final path used? > > >> >> This means that xhr "folder1/data.json" works, but xhr > > >> >> "../someparent/data.json" doesn't? > > >> >> > > >> >> > > >> >> On Wed, Dec 2, 2015 at 4:52 AM Shazron <shaz...@gmail.com> wrote: > > >> >> > > >> >>> Marked the two known failures as pending. Now everything is green > > (and > > >> >>> yellow) across the board for UIWebView and WKWebView. > > >> >>> > > >> >>> On Tue, Dec 1, 2015 at 11:49 PM, Jesse <purplecabb...@gmail.com> > > >> wrote: > > >> >>> >>> Or should I just let it fail still? > > >> >>> > It depends how long it'll be until we fix them. The build will > be > > >> broken > > >> >>> > in the CI until it is fixed so probably marking them as pending > is > > >> the > > >> >>> > better option. > > >> >>> > > > >> >>> > > > >> >>> > @purplecabbage > > >> >>> > risingj.com > > >> >>> > > > >> >>> > On Tue, Dec 1, 2015 at 10:42 PM, Shazron <shaz...@gmail.com> > > wrote: > > >> >>> > > > >> >>> >> Couldn't wait. All file-transfer specs now pass for uiwebview > and > > >> >>> >> wkwebview. > > >> >>> >> > > >> >>> >> For those two WKWebView tests that are failing, but are > expected > > to > > >> >>> >> fail -- I'll try to modify the tests to mark the test as > pending > > if > > >> >>> >> the platform is iOS and the WKWebView bridge is found. > > >> >>> >> > > >> >>> >> Or should I just let it fail still? > > >> >>> >> > > >> >>> >> On Tue, Dec 1, 2015 at 9:49 PM, Shazron <shaz...@gmail.com> > > wrote: > > >> >>> >> > Thanks! - yeah after I posted it, of course I realized it is > > all > > >> open > > >> >>> >> > source (duh) and I can run a local server or throw it on a > > >> >>> >> > digitalocean instance or something :) > > >> >>> >> > I'll do that tomorrow... > > >> >>> >> > > > >> >>> >> > On Tue, Dec 1, 2015 at 9:24 PM, Carlos Santana < > > >> csantan...@gmail.com> > > >> >>> >> wrote: > > >> >>> >> >> For a second I read "the bar is clear", but then I went to > my > > >> fridge > > >> >>> and > > >> >>> >> >> saw I still have some beer left :-) > > >> >>> >> >> > > >> >>> >> >> How long before the INFRA provides the VM for the file > > transfer, > > >> I > > >> >>> >> looked > > >> >>> >> >> the JIRA and it mentioned something like "complete" and "we > > are > > >> in > > >> >>> >> holding > > >> >>> >> >> because of capacity" in the same comment, and I was like > > stupid > > >> >>> because > > >> >>> >> I > > >> >>> >> >> didn't understand :-( > > >> >>> >> >> > > >> >>> >> >> If it's going to take a long time, can we do the test with a > > >> local > > >> >>> >> machine > > >> >>> >> >> and vet that it works? > > >> >>> >> >> > > >> >>> >> >> For local xhr loading, I left a comment in the JIRA. I > don't > > >> think > > >> >>> it's > > >> >>> >> >> need it but I'm curios on how local xhr loading works when > > >> fetching > > >> >>> >> normal > > >> >>> >> >> files on a web app, meaning dynamically loading js, css, > html > > in > > >> SPA > > >> >>> >> using > > >> >>> >> >> a typical js framework like angular, etc.. > > >> >>> >> >> > > >> >>> >> >> Platform API is [5], I think is nice to have but not > required > > >> for the > > >> >>> >> 4.0 > > >> >>> >> >> release. > > >> >>> >> >> > > >> >>> >> >> Oh by the way GREAT PROGRESS !!! and I cheers , I'm having a > > beer > > >> >>> now. > > >> >>> >> >> > > >> >>> >> >> > > >> >>> >> >> > > >> >>> >> >> On Tue, Dec 1, 2015 at 8:38 PM Shazron <shaz...@gmail.com> > > >> wrote: > > >> >>> >> >> > > >> >>> >> >>> The board is almost clear [1]. > > >> >>> >> >>> > > >> >>> >> >>> UIWebView mobile-spec passes, just waiting for INFRA-10831 > > [2] > > >> for > > >> >>> the > > >> >>> >> >>> file-transfer tests. > > >> >>> >> >>> Ditto for WKWebView, it essentially just fails two tests, > > which > > >> are > > >> >>> >> >>> expected [3] > > >> >>> >> >>> (filed a feature request issue [4] for local xhr loading, > if > > >> >>> needed). > > >> >>> >> >>> > > >> >>> >> >>> Platform API [4] could go in this release as well, what do > > you > > >> >>> think? > > >> >>> >> >>> > > >> >>> >> >>> --- > > >> >>> >> >>> > > >> >>> >> >>> [1] > > >> >>> > https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=76 > > >> >>> >> >>> [2] https://issues.apache.org/jira/browse/INFRA-10831 > > >> >>> >> >>> [3] > > >> >>> >> >>> > > >> >>> >> > > >> >>> > > >> > > > https://issues.apache.org/jira/browse/CB-7287?focusedCommentId=15034831&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15034831 > > >> >>> >> >>> [4] https://issues.apache.org/jira/browse/CB-10109 > > >> >>> >> >>> [5] https://github.com/apache/cordova-ios/pull/176 > > >> >>> >> >>> > > >> >>> >> >>> > > >> >>> > > --------------------------------------------------------------------- > > >> >>> >> >>> 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 > > >> >>> >> > > >> >>> >> > > >> >>> > > >> >>> > > --------------------------------------------------------------------- > > >> >>> 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 > > >> > > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > >
