1384030 - Enable setting <input type=file>.files

Status: RESOLVED FIXED

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

Description

[Anne (:annevk)]

Standard change: https://github.com/whatwg/html/pull/2866

Tests: https://github.com/w3c/web-platform-tests/issues/6617

All other browsers allow this. I'm surprised it hasn't been a compatibility issue thus far.

Comment 1

[Šime Vidas]

I've created a live demo for the main use case: https://output.jsbin.com/vaxagel/quiet. Seems useful.

Comment 2

[Ben Tian (inactive)]

Attachment: Patch 1 (v1): Enable setting <input type=file>.files

WIP patch that passes comment 0 web platform test.

Comment 3

[Ben Tian (inactive)]

Attachment: Patch 1 (v2): Enable setting <input type=file>.files

Change
- update |mFileData->mFilesOrDirectories| according to |aFiles| to set

Comment 4

[Ben Tian (inactive)]

Attachment: Patch 1 (v3): Enable setting <input type=file>.files

Change:
- Clear old file list first to update new file list without copy

Comment 5

[Ben Tian (inactive)]

Attachment: [final] Patch 1: Enable setting <input type=file>.files, r=smaug

Change:
- Fix wpt failure of html/dom/interfaces.html

=====

Olli, can you review may patch that enables setter of <input type=file>.files?

The patch is verified with comment 0 wpt test, comment 1 demo, and on try:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=c28e938b70d1cd3167d11c1fb89c3311b2737d6f

Comment 6

[Anne (:annevk)]

r+ for testing/web-platform/ changes.

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8895201 [details] [diff] [review]
[final] Patch 1: Enable setting <input type=file>.files, r=smaug

Could you please extend the wpt for this to ensure that after setting .files using FormData gets the new files. The current wpt is very limited.
https://xhr.spec.whatwg.org/#interface-formdata

Comment 8

[Ben Tian (inactive)]

(In reply to Olli Pettay [:smaug] from comment #7)
> Could you please extend the wpt for this to ensure that after setting .files
> using FormData gets the new files. The current wpt is very limited.
> https://xhr.spec.whatwg.org/#interface-formdata

Sure will check and update wpt PR here.

---
My idea is to apply following steps but step 1) may require manual operation as [1] since FileList has no constructor [2].
1) create FileList that includes file 'upload.txt' and assign to input1.files
2) assign input1.files to input2.files
3) extract input2.files to FormData as [3] and ensure upload.txt exists.

[1] https://github.com/w3c/web-platform-tests/blob/master/FileAPI/filelist-section/filelist_selected_file-manual.html
[2] https://w3c.github.io/FileAPI/#filelist-section
[3] https://developer.mozilla.org/en-US/docs/Web/API/FormData/Using_FormData_Objects#Creating_a_FormData_object_from_scratch

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

Ah, hmm, if wpt test is hard, mochitest is ok too. There you could use SpecialPowers.wrap to access inputElement.mozSetFileArray

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/03ed4db276ca
Enable setting <input type=file>.files. r=smaug

Comment 11

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/03ed4db276ca

Comment 12

[Ben Tian (inactive)]

Opened Bug 1390394 to track test for comment 7.

Comment 13

[Chris Mills [:cmills]]

I've documented this, mentioning it in the appropriate places:

https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputElement (this page is a bit of a mess right now, and needs cleaning up, but that's a job for another day)
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/file#Getting_information_on_selected_files

I've also added a note to the Fx57 rel notes:

https://developer.mozilla.org/en-US/Firefox/Releases/57#DOM

Let me know if that's OK. Thanks!

Comment 14

[Ben Tian (inactive)]

LGTM. Thanks Chris!.

(In reply to Chris Mills (Mozilla, MDN editor) [:cmills] from comment #13)
> I've documented this, mentioning it in the appropriate places:
> 
> https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputElement (this page
> is a bit of a mess right now, and needs cleaning up, but that's a job for
> another day)
> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/
> file#Getting_information_on_selected_files
> 
> I've also added a note to the Fx57 rel notes:
> 
> https://developer.mozilla.org/en-US/Firefox/Releases/57#DOM
> 
> Let me know if that's OK. Thanks!

Comment 15

[guest271314]

Is the expected result for change event to be dispatched when .files property is set at <input type="file"> element?

Comment 16

[Ben Tian (inactive)]

(In reply to guest271314 from comment #15)
> Is the expected result for change event to be dispatched when .files
> property is set at <input type="file"> element?

ni? Anne to comment.

--
My thought is yes for drag-and-drop case [1] but no for non-user activated cases like [2].

[1] https://github.com/whatwg/html/issues/2861
[2] https://github.com/w3c/web-platform-tests/blob/master/html/semantics/forms/the-input-element/files.html#L61

Comment 17

[Anne (:annevk)]

I think whenever .files is set there should be no event. Just like setting .value dispatches no event.

Comment 18

[guest271314]

(In reply to Ben Tian [:btian] from comment #16)
> (In reply to guest271314 from comment #15)
> > Is the expected result for change event to be dispatched when .files
> > property is set at <input type="file"> element?
> 
> ni? Anne to comment.
> 
> --
> My thought is yes for drag-and-drop case [1] but no for non-user activated
> cases like [2].
> 
> [1] https://github.com/whatwg/html/issues/2861
> [2]
> https://github.com/w3c/web-platform-tests/blob/master/html/semantics/forms/
> the-input-element/files.html#L61

How would the two cases be distinguished?

Comment 19

[guest271314]

(In reply to Anne (:annevk) from comment #17)
> I think whenever .files is set there should be no event. Just like setting
> .value dispatches no event.

The change event is dispatched at Chromium 62 when .files is set, the event is not dispatched at Firefox 57. From perspective here the event should be dispatched when the property is set programatically or in response to user action. 

Curious if the reason that the event is not dispatched at Firefox is due to the mechanism by which the FileList is observed? That is, if a new FileList is set that FileList is not the same as the one proeviously observed before being replaced by the new FileList?

Comment 20

[guest271314]

(In reply to Anne (:annevk) from comment #17)
> I think whenever .files is set there should be no event. Just like setting
> .value dispatches no event.

You do have a valid point for not dispatching change event for a case such as 

const input = document.createElement("input");

const data = [
  new File(["a"], "a.txt")
, new File(["b"], "b.txt")
];

input.type = "file";

input.name = "files[]";

input.multiple = true;
// set `File` objects at `FileList`
input.files[Symbol.iterator] = function*() {
   for (const file of data) {
     yield file
   };
};

Comment 21

[guest271314]

Is the distinction, if any, between user action setting .files and programmically setting .files property moot?

Comment 22

[Anne (:annevk)]

FWIW, guest271314 took ownership of this in https://github.com/whatwg/html/issues/3269#issuecomment-349533348 and filed issues against Chrome and Safari. If they won't remove we'll consider changing the specification at which point Firefox will get a fresh bug.

Thanks again for doing that and sorry again for not getting back to you sooner.