Intent to implement and ship: Settable .files attribute on HTMLInputElement

[Boris Zbarsky]

Summary: This allows assigning to a file input from script when getting
a file drop event, amongst other use cases.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=757664

Standards status: Incessant wrangling. Everyone agrees this would be
good to do, in general. Chrome implements something where you can
assign a FileList to HTMLInputElement.files. See below for our proposed
behavior.

Platform coverage: all

Estimated or target release: Gecko 40.

Preference behind which this will be implemented: None for the moment.
If necessary, we could sorta put this behind a pref or channel ifdef,
but it would still have observably different behavior from what we have
now when the setter is actually invoked (either strict mode would no-op
instead of throwing or non-strict mode would throw instead of no-opping).

DevTools bug: Doesn't seem applicable.

The behavior we propose to implement:

1) The setter treats its single argument as a sequence<Blob>. Any
Blobs that are not already Files get upgraded to Files, identical to how
https://xhr.spec.whatwg.org/#create-an-entry behaves.

2) If the input is not in the "file" state after the argument coercion
described in step 1, the operation is a no-op (as opposed to throwing).

3) The existing .files value, if any, is thrown away and a new FileList
created in its place.

-Boris

[Boris Zbarsky]

On 4/10/15 2:24 PM, Boris Zbarsky wrote:
> 1) The setter treats its single argument as a sequence<Blob>

More precisely, nullable sequence. If null is assigned and the input is
in file state, the file list is cleared.

-Boris

[Jonas Sicking]

On Fri, Apr 10, 2015 at 11:24 AM, Boris Zbarsky <bzba...@mit.edu> wrote:
> 1) The setter treats its single argument as a sequence<Blob>. Any Blobs
> that are not already Files get upgraded to Files, identical to how
> https://xhr.spec.whatwg.org/#create-an-entry behaves.

Is there a reason to upgrade to File? I thought it'd be good to keep
the object identities the same as much as possible (except for the
sequence object itself of course).

/ Jonas

[Boris Zbarsky]

On 4/10/15 6:23 PM, Jonas Sicking wrote:
> Is there a reason to upgrade to File?

Yes. FileList claims to return Files.

We could change that to have it return Blobs, of course, and then make
sure that various consumers (at least the internal ones) can deal.

-Boris

[Jonas Sicking]

I think that's the way to go.

One option is to make the xpidl interface always return a File, but
make the .webidl interface return files or blobs.

We'd still have to check internal JS consumers though. But I think
that's the right thing to do.

/ Jonas

[Boris Zbarsky]

On 4/10/15 7:43 PM, Jonas Sicking wrote:
> One option is to make the xpidl interface always return a File, but
> make the .webidl interface return files or blobs.

Why, exactly? If we want to do this, just have them both return a Blob
in terms of the IDL. If it happens to be a Blob that's also a File, fine.

> We'd still have to check internal JS consumers though. But I think
> that's the right thing to do.

I'm more worried about internal C++ consumers, honestly. Have to audit
them all to make sure they're not assuming they can get a filename and such.

It'd be less painful to audit this if we didn't internally use "File" to
refer to Blobs. :(

-Boris

[Boris Zbarsky]

On 4/10/15 10:15 PM, Boris Zbarsky wrote:
> I'm more worried about internal C++ consumers, honestly. Have to audit
> them all to make sure they're not assuming they can get a filename and
> such.

For example, HTMLInputElement::GetValueInternal or
HTMLInputElement::AfterSetFiles will do mFiles[0]->GetMozFullPath. This
will land in FileImplBase::GetMozFullPath which will proceed to assert
mIsFile. Which will be false if mFiles[0] is a Blob...

I'm sure there's other fun bits like that hiding in there too.

-Boris

[Jonas Sicking]

On Fri, Apr 10, 2015 at 7:15 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
> On 4/10/15 7:43 PM, Jonas Sicking wrote:
>>
>> One option is to make the xpidl interface always return a File, but
>> make the .webidl interface return files or blobs.
>
> Why, exactly? If we want to do this, just have them both return a Blob in
> terms of the IDL. If it happens to be a Blob that's also a File, fine.

So that C++ callers, which go through the xpidl interface, would still
get a real File wrapping the Blob, but JS callers would just get the
Blob.

Though if we're only worried about internal C++ callers, then I
suspect it's easier to audit than to add this complexity.

/ Jonas

[Boris Zbarsky]

On 4/11/15 4:53 AM, Jonas Sicking wrote:
> So that C++ callers, which go through the xpidl interface, would still
> get a real File wrapping the Blob

C++ callers don't go through the xpidl interface.

> Though if we're only worried about internal C++ callers

Precisely.

-Boris

[Anne van Kesteren]

On Sat, Apr 11, 2015 at 12:23 AM, Jonas Sicking <jo...@sicking.cc> wrote:
> Is there a reason to upgrade to File? I thought it'd be good to keep
> the object identities the same as much as possible (except for the
> sequence object itself of course).

FWIW, FormData also upgrades to File (and gives Blob objects a
filename of "blob" in the process). Would make some sense to me if
these are similar.


--
https://annevankesteren.nl/

[Boris Zbarsky]

On 4/12/15 2:58 AM, Anne van Kesteren wrote:
> On Sat, Apr 11, 2015 at 12:23 AM, Jonas Sicking <jo...@sicking.cc> wrote:
>> Is there a reason to upgrade to File? I thought it'd be good to keep
>> the object identities the same as much as possible (except for the
>> sequence object itself of course).
>
> FWIW, FormData also upgrades to File (and gives Blob objects a
> filename of "blob" in the process).

Precisely. I'm actually using the exact same code for the .files setter.

Note that we'd have to do something like this anyway at submit time, in
that the submitted data would need a made-up filename. And it feels
weird to allow doing something via the .files setter (add a Blob but not
File to the file list) that you can't do with FormData...

I'm not sure I see much in the way of upsides to not upgrading Blobs
here. I do see a bunch of downsides.

-Boris