File upload (test "#type -> file upload") doesn't work locally

[sap1ens]

I'm running "#type -> file upload" test from Element.js suite. It works when I run it with browserstack, but it doesn't work locally.

Steps to reproduce:

1. Install chromedriver (for example brew install chromedriver)
2. Run chromedriver (for example chromedriver --port=4444 --url-base=wd/hub &)
3. In tests/intern.js replace tunnel: 'BrowserStackTunnel' with tunnel: 'NullTunnel'
4. Run "#type -> file upload" test from Element.js suite

Expected output: successful test

Actual output:

FAIL: chrome 39 on MAC - Element - #type -> file upload
CancelError: Timeout reached on chrome 39 on MAC - Element - #type -> file upload
  at null.<anonymous>  <node_modules/intern/lib/Test.js:162:20>
  at Timer.listOnTimeout  <timers.js:119:15>

So, nothing happens. I tried to increase different timeouts - didn't help.

Additional details:
OS X 10.10.4
ChromeDriver 2.17.340128 (994135a3538dd99439ef22cea8a9b098e00d8eb4)
Chrome 44.0.2403.157
Leadfoot: master branch

[sap1ens]

I found the root cause.

By default, leadfoot detects remoteFiles capability and if it's true it tries to archive provided file and send it as base64.

But in case of local upload, you have to skip the whole archiving / base64 part and behave like filename is a simple string. In this case chromedriver (or any other normal driver) will detect the file locally and process it properly.

So, disabling this block https://github.com/theintern/leadfoot/blob/master/Element.js#L196 for local upload solves the issue. What is the best option to do it? Is there any way to detect remote vs. local driver? If not - what is the best way to provide additional configuration option, something like disableRemoteFiles?

[csnover]

Hmmmmmm. That’s quite odd. When the file is uploaded to Selenium it is unpacked into a temporary directory so it shouldn’t matter whether it is remote or not. When I tested this functionality I was actually using an SSH tunnel between two systems, so while the filesystems were separate, they both appeared to be local to the other, even though they were not. So, I am not totally sure offhand how the mechanism would ever fail in the case you’re describing. Actually, the feature detection verifies that the server returns a path with the expected filename in it, so I am really not sure how it would fail.

[csnover]

To answer your last questions, making feature detection tests in https://github.com/theintern/leadfoot/blob/master/Server.js#L329 not run if values were explicitly defined for those features in desiredCapabilities might be the best way to go, then anything can be overridden by anyone. As a user, you could also just disable feature detection entirely by setting fixSessionCapabilities to false which would also disable remote file capability.

[sap1ens]

Regarding your other answer, I've tried to use desiredCapabilities for specifying remoteFiles to be false, but the detection code will override the specified value anyway: https://github.com/theintern/leadfoot/blob/master/Server.js#L804 (there is no check before that), I might fix it with PR tomorrow :)

[sap1ens]

So, if you could just reproduce my steps locally you'll see that currently leadfoot is broken. We have to disable remoteFiles to make it work.

[csnover]

WebDrivers don’t support archiving / unarchiving files by themselves, they require file to be presented locally.

And if the file gets uploaded, it becomes presented wherever the server is, no matter whether it is on the same machine or not.

All of the things you reference before from Selenium code are not relevant to this because remoteFiles will be false if the remote server doesn’t support the file upload command, which is the whole point of the feature detection!

The actual bug is that the type command gets stuck in a loop for local servers that support uploads because it recursively calls itself. On the first recursive call it sees that, yep, the provided file path exists on the local machine, so it must need to be uploaded, so it uploads the already uploaded file a second time, ad nauseam. The fix is to call this._post('value') directly after the upload is done instead of calling this.type again in Element#type.

[sap1ens]

Sorry, I think I assumed too much based on the codebase instead of actual debugging. My bad.

I can confirm the loop, yes. I attempted to do the fix, I replaced

if (fs.existsSync(filename)) {
    return this.session._uploadFile(filename).then(this.type.bind(this));
}

with

if (fs.existsSync(filename)) {
    var self = this;
    return this.session._uploadFile(filename).then(function(uploadedFilename) {
        self._post('value', {
            value: uploadedFilename
        }).then(noop);
    });
}

is that what you mean?

It still doesn't work for me.

[csnover]

You’ll need to return the inner call.

[sap1ens]

Fixed in #55, as you suggested.