Anne (:annevk) Reporter
	Description • 7 years ago

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.

	Šime Vidas
	Comment 1 • 7 years ago

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

	Ben Tian (inactive) Assignee
	Comment 2 • 7 years ago

WIP patch that passes comment 0 web platform test.

	Ben Tian (inactive) Assignee
	Comment 3 • 7 years ago

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

	Ben Tian (inactive) Assignee
	Comment 4 • 7 years ago

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

	Ben Tian (inactive) Assignee
	Comment 5 • 7 years ago

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

	Anne (:annevk) Reporter
	Comment 6 • 7 years ago

r+ for testing/web-platform/ changes.

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 7 • 7 years ago

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

	Ben Tian (inactive) Assignee
	Comment 8 • 7 years ago

(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

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 9 • 7 years ago

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

	Pulsebot
	Comment 10 • 7 years ago

Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/03ed4db276ca
Enable setting <input type=file>.files. r=smaug

	Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)
	Comment 11 • 7 years ago
bugherder

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

	Ben Tian (inactive) Assignee
	Comment 12 • 7 years ago

Opened Bug 1390394 to track test for comment 7.

	Chris Mills [:cmills]
	Comment 13 • 7 years ago

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!

	Ben Tian (inactive) Assignee
	Comment 14 • 7 years ago

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!

	guest271314
	Comment 15 • 7 years ago

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

	Ben Tian (inactive) Assignee
	Comment 16 • 7 years ago

(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

	Anne (:annevk) Reporter
	Comment 17 • 7 years ago

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

	guest271314
	Comment 18 • 7 years ago

(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?

	guest271314
	Comment 19 • 7 years ago

(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?

	guest271314
	Comment 20 • 7 years ago

(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
   };
};

	guest271314
	Comment 21 • 7 years ago

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

	Anne (:annevk) Reporter
	Comment 22 • 7 years ago

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.