cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse <purplecabb...@gmail.com>
Subject Re: [Testing] No content to speak of
Date Mon, 25 Aug 2014 23:51:30 GMT
Okay, thanks all, I am digging in now too for wp8, and windows, I don't
think that change was intentional in Entry.js, but I'll see soon.

Moving the rest of conversation to CB-7375
<https://issues.apache.org/jira/browse/CB-7375>, This thread was meant to
test communication, which has passed.

@purplecabbage
risingj.com


On Mon, Aug 25, 2014 at 4:46 PM, Martin Gonzalez <
martin.c.glez.glez@gmail.com> wrote:

> The reason of this fails as Ian pointed out are the references to the
> filesystem on the entry.
> 125 Expected --> FileSystem: persistent  ; Returned :temporary
> 126 Expected --> FileSystem: temporary   ; Returned :persistent
> 127 Expected --> FileSystem: persistent  ; Returned :temporary
> 128 Expected --> FileSystem: temporary   ; Returned :persistent
>
> I've got this results, getting the filesystem property from the entry.
>
> I've created an issue related to this subject, in order to fix it for all
> platforms.
> https://issues.apache.org/jira/browse/CB-7375
>
>
>
> 2014-08-25 18:31 GMT-05:00 Ian Clelland <iclelland@chromium.org>:
>
> > The changes to Entry.js introduce this failure; for some reason the
> > reference to entry.filesystemName was replaced with
> entry.filesystem.name,
> > and so the entry is not being returned with a reference to the correct
> > filesystem.
> >
> > I think that this was a change made to accommodate Windows Phone, which
> > broke Android (and probably iOS). There's a fundamental difference
> between
> > how we have to pass the filesystem object across the bridge vs. how we
> can
> > pass it around in JavaScript, and this change makes one style work, at
> the
> > expense of the other.
> >
> > I'll see this evening if I can work up a version that will work for both,
> > and get some WP8 testers to look at it in the morning.
> >
> > Ian
> >
> >
> > On Mon, Aug 25, 2014 at 7:06 PM, Jesse <purplecabbage@gmail.com> wrote:
> >
> > > Which tests are now failing, what do they test, and how have you
> verified
> > > that they should pass? Just because they used to pass, does not mean
> they
> > > are valid, or should have passed.
> > >
> > > This change to DirectoryEntry.js makes perfect sense, and may have
> > > uncovered a previously passing test that should have failed.
> > >
> > > -    if (!/\/$/.test(nativeURL)) {
> > > +    if (nativeURL && !/\/$/.test(nativeURL)) {
> > >          nativeURL += "/";
> > >      }
> > >
> > > Similarily, the changes to www/resolveLocalFileSystemURI.js and
> > > www/Entry.js do not appear to introduce a new failure, but could be
> > > uncovering previously falsely passing test(s)
> > >
> > >
> > >
> > > @purplecabbage
> > > risingj.com
> > >
> > >
> > > On Mon, Aug 25, 2014 at 3:56 PM, Martin Gonzalez <
> > > martin.c.glez.glez@gmail.com> wrote:
> > >
> > > > The tests shouldn't be failing. I agree with Ian, the tests started
> to
> > > fail
> > > > after:
> > > > 0ffb969 (Fixes multiple mobilespec tests
> > > > errors). I've verified with the previous commit and everything works
> as
> > > > expected.
> > > >  On Aug 25, 2014 5:46 PM, "Jesse" <purplecabbage@gmail.com> wrote:
> > > >
> > > > > I was just noting a possible reason for the tests to now fail.
> > > > > Has anyone verified whether they should fail or not?
> > > > >
> > > > > @purplecabbage
> > > > > risingj.com
> > > > >
> > > > >
> > > > > On Mon, Aug 25, 2014 at 3:27 PM, Michal Mocny <mmocny@chromium.org
> >
> > > > wrote:
> > > > >
> > > > > > The 4 failing file tests were reported on JIRA (
> > > > > > https://issues.apache.org/jira/browse/CB-7093) and I thought
> > > > > Martin/Jesse
> > > > > > were looking at them.
> > > > > >
> > > > > >
> > > > > > On Mon, Aug 25, 2014 at 5:39 PM, Marcel Kinard <
> cmarcelk@gmail.com
> > >
> > > > > wrote:
> > > > > >
> > > > > > > Yes, all the other automated tests (except the 4 File tests
as
> > > > > previously
> > > > > > > noted) are running successfully, so that does seem to point
> > > somewhere
> > > > > > else
> > > > > > > besides the bridge.
> > > > > > >
> > > > > > > The issue appears to be related to CB-6764. If I remove
from
> > > > > > mobile-spec's
> > > > > > > index.html the script reference to "doesnotexist/notcordova.js"
> > > then
> > > > > the
> > > > > > > device object and the yellow box gets populated properly.
> > > > > > >
> > > > > > > On Aug 25, 2014, at 4:23 PM, Ian Clelland <
> > iclelland@chromium.org>
> > > > > > wrote:
> > > > > > >
> > > > > > > > Usually an empty yellow box on startup means that
the bridge
> > > isn't
> > > > > > > working,
> > > > > > > > but if you're seeing ~300 other successful tests,
then that's
> > > > > unlikely
> > > > > > to
> > > > > > > > be the problem.
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
>
> --
> Regards,
> Martin Gonzalez
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message