1494803 - Reset HTMLInputElement value (so change event is dispatched) when file picker is closed without selecting a file

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, defect, P2)

Description

[Peter Linss]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:62.0) Gecko/20100101 Firefox/62.0
Build ID: 20180830143136

Steps to reproduce:

Create an <input type=file> and click on it. In the resulting dialog, click 'Cancel'.


Actual results:

The dialog closes as expected, but this is entirely undetectable by the web page.


Expected results:

Ideally there should be a 'cancel' event or some such. But other browsers at least have predictable side effects. For example, in Chrome the <input> sometimes receives a 'change' event (if the control had a value before the activation, and the cancel clears the value), also in Chrome and Safari the window loses focus when the dialog opens, and regains focus when the dialog closes. In Firefox, the window may gain focus by the user clicking the input control, but no focus events happen as the dialog opens and closes.

Comment 1

[Andrew Overholt [:overholt]]

baku knows about these things :)

Comment 2

[Andrea Marchesini [:baku]]

When the file picker is closed without selecting a file, Firefox doesn't reset the previous value, and for this reason, the change event is not dispatched. Differently, chromium resets the HTMLInputElement value.
The spec doesn't say anything about what the right behavior should be when the file picker is canceled.

I think it makes sense to implement the chromium behavior, because otherwise, it's not possible to unset the value of a HTMLInputElement type=file.

Comment 3

[Andrea Marchesini [:baku]]

Madhava, I would like to have a feedback from a UX point of view.

So far, in firefox, a HTMLInputElement type="file" allows the selection of files, via file picker or drag&drop. If the file picker is canceled, we don't reset the previous value, but, instead, we keep the last file selected (if any).
Differently, chromium and safari reset the HTMLInputElement value when the file picker is canceled.

I guess, the idea behind the firefox approach is that, canceling a file picker should only abort the current file selection, and this should not interfere with the previous state of the HTMLInputElement.

What do you think is the correct approach from a user-experience point of view? Thanks.

Comment 4

[Peter Linss]

Please note that while resetting the HTMLInputElement on cancel will increase compat with Chrome and Safari (and I agree it's questionable from a UX perspective), that alone doesn't solve the original issue, because you'll only get a change event if the input previously had a value, so a cancel on the first open won't trigger that.

Changing the focus from the window while the file picker dialog is open will be more valuable. (Though the proper fix here will be to add a cancel event, I'll file an issue on the HTML spec for that.)

Comment 5

[Peter Linss]

Issue filed on the HTML spec: https://github.com/whatwg/html/issues/4061

Comment 6

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hi Markus, are you the right person to ask for UX inputs in comment 3? Or perhaps you could point to the right person? Thanks!

Comment 7

[Markus Jaritz [:designakt] (UX)]

I fully agree with what Peter says in comment #4.

Canceling a dialog does not equal removing a previous input. We should stick with our behavior.

Over the last years I noticed more and more website starting uploads automatically once a file is selected, so people will not get the chance to notice the difference and clear a selected file.

(In reply to Peter Linss from comment #4)

Please note that while resetting the HTMLInputElement on cancel will
increase compat with Chrome and Safari (and I agree it's questionable from a
UX perspective), that alone doesn't solve the original issue, because you'll
only get a change event if the input previously had a value, so a cancel on
the first open won't trigger that.

Changing the focus from the window while the file picker dialog is open will
be more valuable. (Though the proper fix here will be to add a cancel event,
I'll file an issue on the HTML spec for that.)

Comment 8

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Thanks Markus for the input. Based on that, I'll close this as wontfix. Feel free to reopen if I miss something.
I'll file another bug for tracking comment 5.