Closed Bug 1422655 Opened 7 years ago Closed 7 years ago

input[type=file] files settable to arbitrary files

Categories

(Core :: DOM: File, enhancement)

58 Branch
enhancement
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: tristan.fraipont, Unassigned)

Details

Attachments

(1 file, 1 obsolete file)

Attached file input_files_bug.html (obsolete) —
Since bug 1384030[1] we are now able to set the `files` property of an input[type=file] to an other FileList.

I may have misread the fifth comment[2] of specs PR, but I thought this would be limited to user-provided Files, i.e, that we wouldn't be able to set programmatically arbitrary Files.

However, it seems to be possible to workaround this limitation by using a DataTransfer instance created from a ClipboardEvent[3] which does have an accessible Constructor.
See the gist made by this person at https://gist.github.com/guest271314/7eac2c21911f5e40f48933ac78e518bd or the attachment.

Note that Chrome does not allow us to access a ClipboardDataEvent's items property when this instance has been created via the Constructor, but they do allow the creation of a DataTransfer object directly through the window.DataTransfer constructor, whereas Firefox throws an Illegal Invocation in such case.

Maybe specs' github would be a better place to file a bug report, but I thought we should let you know before this becomes more public.

What I can see from this situation: 

.1 If it is allowed to set arbitrary Files to a FileList, then let's implement methods directly on FileList object to do so.
.2 If it is not allowed, add an unsafe flag when adding a File to a ClipboardData's FileList, or proceed like chrome and block the access to the DataTransfer.items property.
.3 ...



[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1384030
[2] https://github.com/whatwg/html/issues/2861#issuecomment-317657810
[3] https://developer.mozilla.org/en-US/docs/Web/API/ClipboardEvent/ClipboardEvent

Note: I am not setting the "Security" option for now since Chrome is also concerned by this, and that I might reference this bug in there too.
Attachment #8934029 - Attachment is obsolete: true
Actually, chrome's behavior about DataTransfer's constructor is in accordance with the new specs[1], which state that the drag-data-store mode should be set as "read/write"...

[1] https://html.spec.whatwg.org/multipage/dnd.html#datatransfer
So it seems it will be allowed anyway[1], and I find the specs about ClipBoardEvent[2] a bit misleading since they seem to imply that if no DataTransfer is passed in the constructor, it should be null, but on the other hand, the very next example implies that this DataTransfer is accessible...

So I'll close a "Invalid", even though I still believe someone might be interested about it...

[1] https://github.com/whatwg/html/issues/3269
[2] https://w3c.github.io/clipboard-apis/#clipboard-event-interfaces
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: