cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <>
Subject Re: FileTransfer tests
Date Fri, 06 Sep 2013 02:58:48 GMT
On Thu, Sep 5, 2013 at 8:45 PM, Jesse <> wrote:

> I am working through some of the failing tests for wp8 filetransfer and
> have some issues with the following tests.  Can anyone add any input on
> where some of the following requirements come from?
> 1. filetransfer.spec.7 should be able to download a file using file://
> (when hosted from file://)
> {code}
> if (!/^file/.exec(remoteFile)) {
>     expect(remoteFile).toMatch(/^file:/);
>     return;
> }
> {/code}
> This will fail on wp7, wp8, and windows8, all of which are NOT loaded from
> the file:// protocol, but have their own specific file-like protocols.
> ( windows phone uses: x-wmapp0:, and windows 8 uses ms-appx:// )
> This should not be a failure, from what I can tell.  I plan to expand the
> test to include the current protocol, + specifically load something using
> the file:// protocol

I suspect that if WP and Win apps cannot be hosted on file:/// URLs, then
this test shoudn't be run on them. We should probably change it, then, to
test that file downloads work from same-scheme / same-host origins.

(I figure that this test exists for platforms like Android, where you have
to explicitly grant the webview access to file:/// URLs from native code,
or else it will not allow you to access them at all, even if your app is
also hosted at that origin.)

I'm not familiar with the WP architecture -- are file:/// resources allowed
at all? Or are all device-local-resources accessed from the custom schemes?

> 2. filetransfer.spec.10 should be stopped by abort() right away
> {code}
> expect(new Date() - startTime).toBeLessThan(300);
> {/code}
> Where does the 300 ms rule come from? Shouldn't this just test that aborted
> downloads do not complete?

The test itself is verifying that file transfers are asynchronous. If it
fails, it means that the ft.abort() call did not get through in 300ms,
which is a good indication that the system was blocking on the transfer.

File transfers should not leave the webview unresponsive, and should handle
abort() calls immediately.

> and that the target file is not partially
> written when aborted?

There's another test for that: filetransfer.spec.9 checks that partial (or
complete) files aren't left around after an abort()ed transfer.

> 3. filetransfer.spec.27 should be able to set custom headers
> {code}
> options.headers = {
>                     "CustomHeader1": "CustomValue1",
>                     "CustomHeader2": ["CustomValue2", "CustomValue3"],
>                 };
> {/code}
> Is it required that we set headers to deeply nested object literals?

I believe this syntax is used to set two values for the same header. This
would appear in the request header as

CustomHeader1: CustomValue1
CustomHeader2: CustomValue2
CustomHeader2: CustomValue3

It should also be allowed to output them like this:

CustomHeader1: CustomValue1
CustomHeader2: CustomValue2, CustomValue3

Is it required that we support non-well-formed object literals? hence the
> extra ','?

No, that's an error.

> 4. Android test / dependency on device
> {code}
> var getMalformedUrl = function() {
>         if (device.platform.match(/Android/i)) {
>             // bad protocol causes a MalformedUrlException on Android
>             return "httpssss://";
>         }...
> {/code}
> This test is dependent on cordova-plugin-device, which may not be present.
> I will switch this to use a userAgent check for Android.

If you can wait until tomorrow, I am planning on fixing this :) Apparently
there's a long-standing feature request somewhere to provide that info as
'cordova.platform', and now that Device is an optional plugin, it makes a
lot more sense. I was lamenting earlier today that I had to do the same
userAgent check in one of our plugins, so I'm just going to take care of it.


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