Provide a (safe) way to enter a filename to upload (e.g. "Enter filename..." on context menu)




Layout: Form Controls
12 years ago
10 years ago


(Reporter: Jesse Ruderman, Unassigned)



Firefox Tracking Flags

(Not tracked)




12 years ago
Bug 258875 removed the ability to enter filenames directly into the file upload control.  Some people complained because:

1) GTK2 and Mac filepickers don't let you enter filenames unless you know secret keyboard shortcuts (Ctrl+L on GTK2, Cmd+Shift+G on Mac).
2) Bug 111821 means Windows filepicker is sometimes slow.
3) Text controls are useful for pasting many filenames with small edits.

(list based on bug 258875 comment 28)

How about creating a context menu for file upload controls that contains "Enter filename..."?  That would still be less convenient than typing filenames directly (which leads to security holes) but it would be more convenient than using filepickers in some cases.


12 years ago
No longer blocks: 258875

Comment 1

12 years ago
As a tech-aware end user, I like the idea alot ;-).  I imagine you'll want some feedback from drivers though.  Possibly a blog post echoed to planet.m.o would be a good "first step" in getting this done.
I'm not sure I understand the rationale here ... presumably the tech-savvy users of the OSes in question would know their own keyboard shortcuts for entering a filename. Also, presumably, if those OSes felt that they were necessary for the native experience for those systems they'd incorporate that UI in a more up-front fashion.

I think the effort would be better spent on fixing bug 111821 than adding a non-OS native widget for entering a filename. I could probably be convinced otherwise, but could someone tell me why on w32, other than the loadtime of the filepicker, it's such an inconvienience to use?

Comment 3

12 years ago
Well the inconvienence also comes when a certain directory has a large number of files, [and by large I mean 1k-10k or more].

Actually being able to type in the filepicker a local address for the file would be a benefit.  (For example, suppose xyz program has daily logs, and unfortunately stores _all_ logs in the _same_ directory, named by date.  [I actually have a program which does that].  Logs themeselves could be as small as 10kb and as large as 10gb [I have a hand-written program to clean out any log older than 7 days, which is also larger than 1gb, but enough with the tangent].  If I know I want a particular _days_ log, what sense is it to force the filepicker to open simply to navigate-to, and then select this file.  [and worse yet if I have to do this multiple times].

Nomatter how "well" Bug 111821 is Fixed, a large enough directory will still be "slow".  This bug itself will not negate the reasoning behind fixing Bug 111821 (imho).  And could even be a (hidden) pref to turn on/off if desired.  [imho] benefits of doing this outweigh the pitfalls.

/me wonders if that mini-rant convinced Mike Beltzner at all.
You've certainly convinced me that GTK and OSX need to expose the "enter a filename" UI in their filepickers a little better :)

If we're thinking of hidden-pref'ing this (which might be a good idea, since I don't think there's a lot of cases for the majority of users where they're entering a bunch of local file names) then maybe the hidden pref should just restore the locally editable text field? That would seem to be more convienient than requiring multiple context-menu clicks to get to the dialog ...

Comment 5

12 years ago
I'd rather add a safe way to enter a filename than add a pref to restore the old way with its security imapct.  Given such a pref, users tend to flip it without understanding the security implications.

Comment 6

12 years ago
Mike, even being a particular tech-savvy user. And one who would personally prefer the "security hole" way.  I would actually advocate the context-menu way, for the same reasons Jesse just stated.  It does have security implication.

Let me give you an example.

Little Johnny is on his uncle's computer, his uncle has a digital camera (which he can use).  Now, Johnny took a picture with the camera of himself, and wants to send it via an webpage e-mail system to a friend.  Johnny heard of this 'hidden' pref.  He searches devmo[?] for documentation on it, and toggles it so he can use it instead of the perceived slow filepicker. He accomplishes the upload, but never flips the pref back.

Now we have a security problem with Uncle Bob's Firefox, that Uncle Bob has no idea how to fix, and we have no idea it is there (since it is a pref).  At the least, if it is context menu, Uncle Bob wont be hit by the possible problems, unless he specifically requests to write in the file-name, via the context menu.
It sounds to me like Uncle Bob's problem is with his twerp of a nephew Jimmy, but I guess I see the point of why a pref is a bad idea.

Still, I don't think it should be our job to fix the crappy filepickers of other operating systems. Let's not pick on Linux any more (it gets enough with me) but on Mac, users are trained to pick files using the mouse, not by keyboard entry. If a user is more used to keyboard entry, I guarantee that they'll know the shortcut for that. If you don't know the shortcut, I guarantee that it's not that big a deal for you as a Mac user. :) Circular (but effective!) logic.

mconnor: I'm suggesting wontfix, but wanted to pass it by you before dropping the hammer.
I wholeheartedly agree.  Providing a workaround for alleged OS filepicker shortcomings isn't a game we want to play.
Last Resolved: 12 years ago
Resolution: --- → WONTFIX
For the record, I just want to state that I was incorrect in my statements in comment 7. Uncle Bob's problem is with his twerp of a nephew *Johnny*. Sorry, I'll try not to let it happen again.


10 years ago
Blocks: 258875
You need to log in before you can comment on or make changes to this bug.