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
