Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of csantana23@gmail.com
 designates 209.85.212.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAKP6k2uvkED9gMO8NeoYYa3W_N4i6UagfbnXCi3i8MDCmN-TWA@mail.gmail.com>
References: 
 <CAK_TSXKxTWie0wRhVnRT0KhZqLhG23MuXrabVsH4uuh6A6xAkg@mail.gmail.com>
	<CAKP6k2u5ZBcsbBEAQqE1VQPD9e_CSipUPuXCpQYAFDB-1cPKxQ@mail.gmail.com>
	<CAK_TSXLGZR5Vche0vXemVPg5Mp43fnvAVHCh8Z0u_fvZ2QAkag@mail.gmail.com>
	<97DCF304-64B8-4A4A-B2C2-31E69662BAEC@gmail.com>
	<CAK_TSXJZroxQA3D97ORvAOin3Aw7ivrjFQufyrYjnnhw_-nPzg@mail.gmail.com>
	<39A9A02D-DC2D-4406-A374-5A05FCABF2D6@gmail.com>
	<CAEeF2TdV-LiJ+0cB0gyDuUBEjn42u7KHejWeHrBnyXoPBoRDog@mail.gmail.com>
	<CAKP6k2tApHBNsRcxJHbxjpk7y9xooMYYM86hWw4Y9St6+9Mq_A@mail.gmail.com>
	<CANOW_pCWyzuf3CVfwOQGC8uhGihO6fsHHB8WvrLTZME8C0bWPA@mail.gmail.com>
	<CAKP6k2t3Xio=7fEJKVcTnzS6WJ64rTkBg64cSUdNkUZzAaFc4w@mail.gmail.com>
	<CAK_TSXJF3j3mqFp0exQYp5HTEFRb=C0QsUBp0MjtkJbKE5G0ng@mail.gmail.com>
	<CANOW_pDYbb-6_m1ae+7ib9ygjn6m6XAnh=Eif3SbEUaUaY5Xbg@mail.gmail.com>
	<CAKP6k2uvkED9gMO8NeoYYa3W_N4i6UagfbnXCi3i8MDCmN-TWA@mail.gmail.com>
Date: Mon, 25 Aug 2014 22:12:38 -0400
Message-ID: 
 <CAHYtTqnG44cHstNaXufKzO2K0WuxKdj6kvnsoofbrxs-M9ktnQ@mail.gmail.com>
Subject: Re: [Testing] No content to speak of
From: Carlos Santana <csantana23@gmail.com>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=f46d0443045673dbd405017ed67b

--f46d0443045673dbd405017ed67b
Content-Type: text/plain; charset=UTF-8

Hey I thought this was a free content thread.

$ ping cordova.io


On Mon, Aug 25, 2014 at 7:51 PM, Jesse <purplecabbage@gmail.com> wrote:

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


-- 
Carlos Santana
<csantana23@gmail.com>

--f46d0443045673dbd405017ed67b--