Closed Bug 1384030 Opened 2 years ago Closed 2 years ago

Enable setting <input type=file>.files

Categories

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

enhancement

Tracking

()

RESOLVED FIXED
mozilla57
Tracking Status
firefox57 --- fixed

People

(Reporter: annevk, Assigned: ben.tian)

Details

(Keywords: dev-doc-complete)

Attachments

(1 file, 3 obsolete files)

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.
Priority: -- → P2
I've created a live demo for the main use case: https://output.jsbin.com/vaxagel/quiet. Seems useful.
WIP patch that passes comment 0 web platform test.
Change
- update |mFileData->mFilesOrDirectories| according to |aFiles| to set
Assignee: nobody → btian
Attachment #8893733 - Attachment is obsolete: true
Change:
- Clear old file list first to update new file list without copy
Attachment #8894727 - Attachment is obsolete: true
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
Attachment #8895201 - Flags: review?(bugs)
r+ for testing/web-platform/ changes.
Attachment #8894794 - Attachment is obsolete: true
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
Attachment #8895201 - Flags: review?(bugs) → review+
Attachment #8895201 - Attachment description: Patch 1 (v4): Enable setting <input type=file>.files → [final] Patch 1: Enable setting <input type=file>.files, r=smaug
Keywords: checkin-needed
(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
Ah, hmm, if wpt test is hard, mochitest is ok too. There you could use SpecialPowers.wrap to access inputElement.mozSetFileArray
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/03ed4db276ca
Enable setting <input type=file>.files. r=smaug
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/03ed4db276ca
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
Opened Bug 1390394 to track test for comment 7.
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!
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!
Is the expected result for change event to be dispatched when .files property is set at <input type="file"> element?
(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
Flags: needinfo?(annevk)
I think whenever .files is set there should be no event. Just like setting .value dispatches no event.
Flags: needinfo?(annevk)
(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?
(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?
(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
   };
};
Is the distinction, if any, between user action setting .files and programmically setting .files property moot?
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.
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.