+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
>
>

Reply via email to