Re: [whatwg] Proposal: API to ask the user for a file
On Mon, 29 Apr 2013, Jonas Sicking wrote: 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. Turns out input type=file.click() wasn't specced yet. I've now specced it, along with hooking it up to the popup-blocking logic. 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. Yeah. On Wed, 1 May 2013, JC wrote: I guess I should have mention too that the existing API is not only unreliable but also very inconvenient. Since the trick depends on the changed event Yeah, it's weird that the dialog doesn't block script (since the dialog is modal). But I would imagine that any new API we added for this would actually be worse in this regard; we'd probably end up with a Promise-based entirely async, non-modal UI. and there's no official way to clear the list of files selected the last time, in order to ensure that the event is fired if the same file is selected again the element has to be removed and replaced by a new one every time the user selects a file That will be resolved once this is fixed: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22682 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: API to ask the user for a file
On Mon, Apr 29, 2013 at 1:41 PM, Ian Hickson i...@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. I have that too, but there's always going to be a manager who thinks that drag and drop is not good enough or not user friendly or they really want to see an upload button (and I happen to have one of those managers). 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. Yes, that's what I said in my proposal. 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. I guess I should have mention too that the existing API is not only unreliable but also very inconvenient. Since the trick depends on the changed event and there's no official way to clear the list of files selected the last time, in order to ensure that the event is fired if the same file is selected again the element has to be removed and replaced by a new one every time the user selects a file, that additional trick is documented here: http://stackoverflow.com/questions/10214947/upload-files-using-input-type-file-field-with-change-event-not-always-firin (and I was neither the person who asked or answered that question, so there's more people struggling with this issue). -- JC
[whatwg] Proposal: API to ask the user for a file
Hi, 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. This may or may not work depending on the browser and version and there's no way to know this other than doing extensive tests. Ideally this, rather common task, should have an official API instead of this hack. The minimum requirements would be to be able to provide a string for the dialog title, a string for the accepted mime types and a boolean to specify whether multiple files can be selected at once, the return value would be a FileList object [1]. This is essentially the same functionality offered by the existing file input element [2] with the only addition of a title for the dialog. A very simple way to provide this functionality would be to add a method to HTMLDocument like this: FileList openFileDialog(DOMString title, DOMString accept, boolean multiple); On success the method would return the list of selected files or null if the used pressed cancel on the dialog. If the user agent can't show the dialog for some reason the method should throw an exception so the developer has the opportunity to do something in this case. Of course there are other options to provide the same functionality, like creating an object to represent the dialog which would allow for asynchronous processing by using callbacks to notify the selected files. One specific request which comes from the project in which I'm currently working is to allow the use of this API from the callbacks of XMLHttpRequest and WebSocket to make possible to have the UI logic on the server, i.e. when the user clicks on a button a message is sent to the server, the business logic in the server defines the behaviour for the button pressed and sends a notification back to the client about what to do which results in this API being invoked. 1. http://dev.w3.org/2006/webapi/FileAPI/#dfn-filelist 2. http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#concept-input-type-file-selected Thank you. -- JC
Re: [whatwg] Proposal: API to ask the user for a file
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.) The minimum requirements would be to be able to provide a string for the dialog title, a string for the accepted mime types and a boolean to specify whether multiple files can be selected at once, the return value would be a FileList object [1]. This is essentially the same functionality offered by the existing file input element [2] with the only addition of a title for the dialog. We could maybe do this if browser vendors are comfortable with it... it's definitely something we want to be really careful about, though. For example, we don't want to set up a situation where a site can trigger a download of a sensitive file (e.g. bank account details) and then trick the user into uploading it by asking the user to Select the file you want to protect from uploading or For debugging purposes, select the newest file in this directory, which is a log file we just generated. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: API to ask the user for a file
On Mon, Apr 29, 2013 at 1:41 PM, Ian Hickson i...@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
