-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Description
When you activate a file input, most (all?) browsers open a file chooser dialog of some sort that allows you to choose a file, or cancel the operation.
However, the specification appears to completely ignore the latter option:
Run these steps in parallel:
Optionally, wait until any prior execution of this algorithm has terminated.
Display a prompt to the user requesting that the user specify some files. If the multiple attribute is not set, there must be no more than one file selected; otherwise, any number may be selected. Files can be from the filesystem or created on the fly, e.g., a picture taken from a camera connected to the user's device.
Wait for the user to have made their selection.
Update the file selection for the input element.
(Side note: "Run these steps in parallel... Wait" is a bit of a contradiction, no?)
Anyway, the language there seems to assume that the user will have made a selection, which may not be the case if the "cancel" button is pressed.
There seems to be at least one difference between browsers as a result of this--in Firefox and WebKit (via the Midori browser), cancelling a file select dialog will retain the previous state of the input and not emit any events, whereas in Chromium, it will change the state of the input to "no files selected" and emit a change event. These were the results on Linux--they may be different on other platforms.
As a result of this, there is currently no cross-browser way to tell if a user has clicked "Cancel" on a file upload dialog. Such a feature would be useful, for instance, if you want to put an "upload file" option in a menu that closes after you upload a file or cancel the dialog.
It would be useful to clarify the intended behavior here. If the intended behavior when canceling/closing the file selection dialog is to empty the file selection and count that as a change, then Firefox and WebKit should change. If the intended behavior is to retain the previous input and not emit a change event, then perhaps a cancel event could be added so that file dialogs opened via JavaScript would always resolve rather than leaving the caller hanging, so to speak?