redesigning <input type="file">
L. David Baron
since we made the textfields not be editable to solve bug 258875 and
related attacks. I think we need to consider redesigning the user
interface for these controls.
I think the first step here is to figure out what the requirements
for the user interface are. Here's a draft:
* fit within the space that Web pages expect file controls to take up
** respond reasonably when resized, within some range (above minimum)
* show what file (or, in the future, files) are currently selected
** maybe emphasizing the leaf name?
* have a way to open the file picker to set the control's value
* have a way to clear the control
* (maybe) ability to copy/paste file names (via context menu?)
* have appropriate appearance for enabled and disabled states
* not look like you can type in it
* consider how it should respond to author and user CSS
** decide which properties should be ignored
** for the rest, decide what they should do
* consider which parts should have native-theme appearance
What am I missing?
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
Boris Zbarsky
> I think the first step here is to figure out what the requirements
> for the user interface are. Here's a draft:
Add "ability to drag a file to the control"?
-Boris
Smaug
>
> Add "ability to drag a file to the control"?
Need to be careful with security on this one.
John J. Barton
...
>
> What am I missing?
I'm not sure this is the correct place:
* the ability to select previously downloaded or stored files
* the ability to start the file search in recently used directories
* an awesome way to find the files
* drag and drop
File upload is tedious with Firefox because it takes a long time for the
OS file selector control to come up and when it does its often in the
wrong part of the filesystem. Some ways to improve this include:
Before the OS control is launched, offer all previous file paths and
their parent directories,
Offer the download/local storage as possible paths (often I am moving
a file between sites),
As the list grows, apply the Places logic to it.
jjb
L. David Baron
> I'm not sure this is the correct place:
> * the ability to select previously downloaded or stored files
> * the ability to start the file search in recently used directories
> * an awesome way to find the files
Because of the security issues, I think these all have to be part of
a dialog that the user chooses to invoke; they can't be one-click
options within the Web page. So I think they all fall within the
"invoke the file picker" point, which could potentially invoke
something better than the OS file picker (whose features vary
significantly between OSes).
Jonas Sicking
> * (maybe) ability to copy/paste file names (via context menu?)
I'd avoid 'paste' at this point since there are security concerns. I.e.
if you can get the user to copy the string '/etc/passwd' and then paste
it to the right place.
Same thing with drag'n'drop support.
I'm not saying we shouldn't look at these features at some point,
however it seems like a good idea to stay away from controversial 'new'
features at this point.
/ Jonas
John J. Barton
> L. David Baron wrote:
>> * (maybe) ability to copy/paste file names (via context menu?)
>
> I'd avoid 'paste' at this point since there are security concerns. I.e.
> if you can get the user to copy the string '/etc/passwd' and then paste
> it to the right place.
Is this different from a web page that instructs them to type
'/etc/passwd' in to the control? The "if you can get the user" part is
exactly what makes this not a security hole.
>
> Same thing with drag'n'drop support.
Yep, same thing. User is draggin' and droppin'
>
> I'm not saying we shouldn't look at these features at some point,
> however it seems like a good idea to stay away from controversial 'new'
> features at this point.
When do we get new reasonable features then? Dealing with files in
Firefox is significantly more painful than it should be.
>
> / Jonas
Boris Zbarsky
>> I'd avoid 'paste' at this point since there are security concerns.
>> I.e. if you can get the user to copy the string '/etc/passwd' and then
>> paste it to the right place.
>
> Is this different from a web page that instructs them to type
> '/etc/passwd' in to the control? The "if you can get the user" part is
> exactly what makes this not a security hole.
Yes, this is somewhat different. It's a lot easier to see that you're
typing in a file input (if we do this right; e.g. if the only way to do
that is via a filepicker) than it is to see that you're pasting into one
if we're not requiring a file picker in the process
>> Same thing with drag'n'drop support.
>
> Yep, same thing. User is draggin' and droppin'
You might not realize that you're dragging a filename (e.g. if you drag
some stuff on the page that happens to serialize to a filename) or for
that matter dropping it on a file input (opacity: 0.001, say).
> When do we get new reasonable features then? Dealing with files in
> Firefox is significantly more painful than it should be.
When we come up with a way of doing it securely. Ideas very much welcome.
-Boris
Jonas Sicking
> Jonas Sicking wrote:
>> L. David Baron wrote:
>>> * (maybe) ability to copy/paste file names (via context menu?)
>>
>> I'd avoid 'paste' at this point since there are security concerns.
>> I.e. if you can get the user to copy the string '/etc/passwd' and then
>> paste it to the right place.
>
> Is this different from a web page that instructs them to type
> '/etc/passwd' in to the control? The "if you can get the user" part is
> exactly what makes this not a security hole.
This is why we have disallowed typing a file-name. We had numerous
exploits due to allowing typing filenames.
>> I'm not saying we shouldn't look at these features at some point,
>> however it seems like a good idea to stay away from controversial 'new'
>> features at this point.
>
> When do we get new reasonable features then? Dealing with files in
> Firefox is significantly more painful than it should be.
Ok, I stand corrected. It's not that we shouldn't focus on adding these
features now. It's that we shouldn't do it as part of rewriting the
existing control.
If you have ideas for how to safely add any features feel free to start
a thread about how to do it. We can do it anytime, but we should treat
it separately to revamping the existing control.
/ Jonas
John J Barton
> What am I missing?
ok more things you don't want to hear:
* paste image
I want web sites to accept a image from the clipboard rather than a
file. I waste a lot of time creating temp files and navigating to them.
jjb
Jonas Sicking
As long as we can do it safely it sounds like a great idea :) But why
limit to images, wouldn't attaching any other type of data from the
clipboard be just as useful?
One thing in general that we need better UI for is attaching images.
Things like image libraries and "webcams" are quite common these days,
it'd be great to integrate with that. The mobile folks have looked into
this, but I think it makes just as much sense for desktop.
There are actually standardized [1] ways for an <input type=file>
element to indicate that it expects an image (accept="image/*"), we
could use that to trigger a control that both allows easy access to
camera/imagelibrary/clipboard, as well as shows a preview of the image.
Similarly accept="video/*" and accept="audio/*" can be used to trigger
custom video/audio uploads.
/ Jonas
[1] http://www.whatwg.org/specs/web-apps/current-work/#attr-input-accept
Ray Kiddy
> L. David Baron wrote:
>> * (maybe) ability to copy/paste file names (via context menu?)
>
> I'd avoid 'paste' at this point since there are security concerns. I.e.
> if you can get the user to copy the string '/etc/passwd' and then paste
> it to the right place.
I am not sure about other platforms, but on the Mac, when one drops a
file, it is not just putting the file name into the pasteboard. It
actually puts several representations of the file onto the drag
pasteboard (which is separate from the cut-and-pasteboard AFAIK), and
the receiver picks out what they are able to deal with.
So, drop a file icon onto a TextEdit document (in plain text mode), and
you get a file name. This is TextEdit's choice. Several information-rich
alternatives are being ignored by TextEdit here.
If a file icon is being dragged onto something for this feature, I think
that there would be enough information available to determine a bunch of
things about the file. There should be enough there to allay concerns
about security.
So, it is not just like "getting the user to type /etc/passwd into a box."
cheers - ray