13119 2011-07-02 10:53:49 +0000 Make the @value attribute in <input> when type="file" work as a suggestion for the OS file picker 2011-08-04 05:01:45 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified All All RESOLVED INVALID P3 enhancement --- 1 brunoaiss ian ayg brunoaiss bzbarsky jonas mike public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 50585 0 brunoaiss 2011-07-02 10:53:49 +0000 I'd like to request to allow the value attribute to specify the text that appears in the filename section in the filepicker when the filepicker is opened. What happens here is the following: I, webmaster, write this code: <input type="file" accept="image/jpg" name="thisfile" value="somefolder/file"> The browser interprets as the following: When the input tag is created its value should be the empty string (just like it is according to the actual specification). When the file picker is opened it should filter the file list according to the accept attribute (just like it is now) and (this part is now) should fill the filename space with the string that is inside value. This can be used in may situations. Including: Sending the user directly to the images folder Sending the user directly to his documents folder Sending the user directly to his desktop Send the file picker to its last folder (the folder it was when it was last closed) (like a: download this file, change it and then upload it) Also, allowing the the javascript to change the @value property would be useful, still it would only change the file picker text and never the value (filepath) itself. This might need a slight improvement but I think, with a little discussion this could have good uses. If this has good uses for applications like word, paint, etc... it should also have applications to internet websites. Specially sites that takes care of content management (like cloud computing?) 50600 1 bzbarsky 2011-07-02 14:21:32 +0000 Mozilla would probably object to implementing this on security grounds. Since pages can put the filepicker up from script, the proposal makes it trivial to use a user holding enter for a bit too long to put up the filepicker, select a file of the web page's choice, and send it to the server. The use cases are good, but we need to solve the above problem before this can end up in the spec. 50603 2 brunoaiss 2011-07-02 19:42:08 +0000 What could be implemented is: When the window is opened a timer starts. If the window has been opened for less than 1s then (you must decide what to do): - Reopen the file picker without saving the previous submitted value (must contain a max nº of times this repeats and know what to do if that counting went to 0) - Don't accept the input. Use the previous value. (I think I'll go with this one) What do you think of this solution? 50605 3 bzbarsky 2011-07-03 03:56:57 +0000 > If the window has been opened for less than 1s I doubt that's acceptable... it's too short. 3-5s is the standard I've seen used for delays like that. And it would _still_ screw over users who select a file quickly. 50607 4 brunoaiss 2011-07-03 09:51:51 +0000 (In reply to comment #3) > > If the window has been opened for less than 1s > > I doubt that's acceptable... it's too short. 3-5s is the standard I've seen > used for delays like that. > > And it would _still_ screw over users who select a file quickly. I've made tests with people that are slow working with the file picker and with people that are fast with the file picker. The slow ones, take about 1s to react that the file picker have appeared. I asked 4 slow people to go to a webpage where I'd open the file picker when they less expected and see how would they react. The 1s is too little, 2s works ok, 3s still ok. For experienced people, like me, the only reason to speed up the select of open is to check the file and give the ok. To accomplish that, I was the fastest in the tests I made (not many people actually) and I toke almost but not quite 3s to: Confirm the filepicker was opened (about 0,4s). Locate the file to pick (about 0,7s) (if it was to confirm what was selected, it would be about the same) move the mouse to the file to dblclick. Probably the 2s is the best one and better than 1s... What do you think? 50614 5 bzbarsky 2011-07-03 14:49:35 +0000 I think this needs review by the security teams of the various browsers, mostly. 50635 6 brunoaiss 2011-07-04 09:44:16 +0000 (In reply to comment #5) > I think this needs review by the security teams of the various browsers, > mostly. is there a way where I can call them all to see this? 50802 7 jonas 2011-07-07 21:52:47 +0000 I agree with Boris, it's unlikely that we'd implement this in Firefox. It's simply too easy to trick the user into selecting a file that they don't intend to share. Here's one attack scenario: 1. Add a <input type=file value="/etc/passwd"> on a page 2. Use CSS to make the <input> 1x1 pixels large 3. Put a <a href="money.html">Click here for free money</a> link on the page 4. Use javascript to detect when the user hovers the above link 5. Use CSS to position the <input> just under the cursor. Once the user attempts to click the link it will instead open a filepicker. Most people's reaction to this would be "get out of my way stupid dialog, I want to click my free-money link" and simply press "OK" in the file picker. This is generally known as the "whatever button". When faced with a dialog people generally don't bother reading its contents but instead think "whatever" and press any button that will allow them to continue with their task. 50835 8 brunoaiss 2011-07-08 10:41:14 +0000 (In reply to comment #7) > I agree with Boris, it's unlikely that we'd implement this in Firefox. It's > simply too easy to trick the user into selecting a file that they don't intend > to share. Here's one attack scenario: > > 1. Add a <input type=file value="/etc/passwd"> on a page > 2. Use CSS to make the <input> 1x1 pixels large > 3. Put a <a href="money.html">Click here for free money</a> link on the page > 4. Use javascript to detect when the user hovers the above link > 5. Use CSS to position the <input> just under the cursor. > > Once the user attempts to click the link it will instead open a filepicker. > Most people's reaction to this would be "get out of my way stupid dialog, I > want to click my free-money link" and simply press "OK" in the file picker. > > This is generally known as the "whatever button". When faced with a dialog > people generally don't bother reading its contents but instead think "whatever" > and press any button that will allow them to continue with their task. I also go with whatever. But instead, I ALWAYS use the cancel button instead of the ok button. Still... I see what you mean... I'll do a worksforme as this is not going to be easy enugh to implement. 52469 9 mike 2011-08-04 05:01:45 +0000 mass-moved component to LC1