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 <[email protected]>: > 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 <[email protected]> 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 < > > [email protected]> 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" <[email protected]> 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 <[email protected]> > > > 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 <[email protected] > > > > > > 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 < > [email protected]> > > > > > 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
