Skip to content

Specify cancelling a file upload from a file input #6376

@adroitwhiz

Description

@adroitwhiz

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:

  1. Optionally, wait until any prior execution of this algorithm has terminated.

  2. 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.

  3. Wait for the user to have made their selection.

  4. 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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    interopImplementations are not interoperable with each otherneeds testsMoving the issue forward requires someone to write teststopic: forms

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions