[whatwg] Proposal: API to ask the user for a file

[Jonas Sicking]

On Mon, Apr 29, 2013 at 1:41 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 29 Apr 2013, JC wrote:
>>
>> So far the only way to ask a user to select a file (e.g. to upload an
>> attachment in a mail client) without showing the ugly "file input" UI is
>> to create one of these elements, hide it somehow, and invoke the "click"
>> method on it and listen for the "changed" event.
>
> You can also just accept a drag-and-dropped file.
>
> Having the <input type=file> UI hidden is probably not supposed to be
> possible (though it's hard for us to stop it), because it means you can
> trick people into clicking the button and bringing up the dialog, which
> can, if you know what browser/OS they're using, let you in some cases
> trick them into uploading a particular file. (It's gotten harder with
> browsers going away from allowing arbitrary text input into that
> control, though, so this might no longer be that big a deal.)

I think all modern browsers intentionally let webpages create custom
UIs for <input type=file> by completely hiding the <input> and then
rendering a custom UI using various <div> and <span> tags. When the
custom UI is clicked the page calls myInputElement.click() in order to
bring up the file picker UI.

Gecko contains some anti-annoyance protections as to prevent the page
from spawning file picker dialogs indefinitely. This is done by
hooking up <input type=file>.click() to popup blocking infrastructure.

So the API being requested here is actually available. But in a really
ugly way through the HTMLInputElement interface.

But I don't really buy the argument that we should supply a new one
because the existing API isn't "reliably available". If the current
API is problematic because there is no way to check if it works, then
I'd prefer to add a way to check if it works, rather than adding a
whole new API.

/ Jonas