Element Send Keys should not use a new line character as separator for multiple files

[whimboo]

Currently the remote steps for "Element Send Keys" allow to set multiple files which then are splitted by new line (\n):

https://w3c.github.io/webdriver/#dfn-element-send-keys

Let files be the result of splitting text on the newline (\n) character.

This is actually broken because some operating systems allow to use new line characters in the filename. Here an example from MacOS:

% touch "foo
\ bar"

% ls
'foo'$'\n''bar'

I discussed this with @andreastt and maybe we should better allow only one file per Element Send Keys invocation, given that there doesn't seem to exist a stable separator across platforms.

Not sure how other drivers are working in regards of that feature. @jimevans mind giving some feedback for IEDriver?

[jimevans]

@whimboo The IE driver does not now support, and never has supported multiple file uploads. I just never got around to implementing it.

[andreastt]

This appears to have been introduced in #505, which unfortunately went under my radar.

I thought we had decided (in Cambridge, MA) that in order for Element Send Keys to work with the new multiple HTML5 feature, it would have to make repeated calls, each containing one file. This would simulate how Element Send Keys appends to a textual form control by appending files to the <input type=file multiple>’s file list and replacing the current file for <input type=file>.

The problem with using a new line character is that file systems we have no control over allow new line characters in the filename. This is a pretty serious correctness problem (and maybe a tiny security issue as well).

[whimboo]

As @andreastt pointed out this was added by #505. @AutomatedTester and @shs96c mind getting some feedback from you both?

Beside that it is also unclear if we want to support multiple uploads, if the already set files are getting replaced (what usually happens when you as user select a single or multiple files), or appended. I think the latter is proposed in the spec.

@jimevans thank you for the feedback.

The chromedriver also makes use of \n:
https://github.com/bayandin/chromedriver/blob/e8675212f852c7e031d4da3838809fadae9b26a8/element_commands.cc#L330

[twalpole]

As @whimboo points out \n was chosen because that's what Selenium used previously, chromedriver supported, and testers/automators are generally in control of the names of the files uploaded. Making repeated calls to append multiple files is not a useful solution for this since no browser works like that. That means the events fired end up being wrong and make it impossible to test apps which support multiple file upload and do things like immediately asynchronously upload those files.

[whimboo]

Interesting use-case I haven't thought about. So yes, in this case the behavior of multiple uploads will be different. Only the very last upload will contain all the files as uploaded, which also means that async uploads might not take place.

Lets wait what @AutomatedTester and @shs96c think about.

[twalpole]

@whimboo In the case of 3 files selected the actual behavior would probably be a single file gets uploaded, then two files get uploaded, then three files get uploaded, due to triggering on the change event and assuming when change is fired all attached files are newly selected as they would be with standard browser behavior. So 6 files uploaded total when it should have only been 3.

[whimboo]

The new command for file uploads (see issue #1355) will cover that. I don't think it makes sense to fix it for Element Send Keys given that we don't actually know which character to use, and if it gets changed, not to regress existing tests.