This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The typing keys section specifies key-based interaction with web elements that are interactable. There's no special casing of input type=file elements which, from a driver perspective, requires special handling. My suggestion is that we allow that to short-curcuit the algorithm and leave the steps to fill filename(s) into the field undefined since the widgets are radically different depending on user agent and operating system. As we discussed at the F2F in Boston we also need to cover input type=file multiple elements. Link to the section: https://dvcs.w3.org/hg/webdriver/raw-file/tip/webdriver-spec.html#typing-keys
Following up on the point about input type=file multiple: The resolution from our F2F in Boston was to follow the logic that sendKeys, by default, appends. Provided the user agent supports the concept of multiple, calling it a second time would append another file. If the user agent doesn't understand this concept, it will replace the set file. Link to the resolution: http://www.w3.org/2013/06/13-testing-minutes.html#item08
Another aspect is: should we check presense of the file or not?
We (In reply to Alexei Barantsev from comment #2) > Another aspect is: should we check presense of the file or not? This is out of scope for WebDriver and is enforced by the user agent.
Unfortunately it is *not* enforced, see https://code.google.com/p/selenium/issues/detail?id=7276
This was put in in https://github.com/w3c/webdriver/commit/de28aa7427f4aea3e3d07e433ae58a8485a72c58 Only missing piece is <input type=file multiple>
subsequent calls to element.send_keys(path) to <input type=file multiple> would append. This needs to be added to the specification