Closed Bug 374011 Opened 17 years ago Closed 12 years ago

Please allow direct input of filename into file upload controls

Categories

(Core :: Layout: Form Controls, enhancement)

Product:
Core
Component:
Layout: Form Controls
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: BijuMailList, Unassigned)

References

Details

Attachments

(1 obsolete file) 

Please allow direct input of filename into file upload controls.
else give an about:config item to do so.
or on context menu an edit option


May be due to bug 258875,
Now it is really irritating to send 5 photos though gmail/yahoo as attachment.
when ever I touch textbox on file control
the F### the file picker pops up.
my picture folders have more than 100 pics
dont ask me to scroll and choose each one.
allow me to select first file then copy/paste/edit rest...
because photos taken on same week are off by 1/2 digits.

I TRUST GMAIL, YAHOO or other sites where me/family upload files!!!
Other than that only few (and well known) forms I go

We dont need bug 258875 for security reasons
you can solve all <input type=file> security issue by following two rule.
1. dont allow script to change focus to and from <input type=file>
2. dont allow script to read keyboard events on <input type=file>
   (onContentChange event is ok)
   (and BTW, stop exposing path of file to script, ie thru element.value)

I thing item 1 is already solved.
fixing item 2 is equivalent to insisting same orgin policy.
ie, just visualize <input type=file> as an <iframe> showing local drive file.
and the text box as its location bar.
Severity: blocker → enhancement
Target Milestone: mozilla1.9beta → ---
OS: Windows XP → All
Hardware: PC → All
A workaround: dragdropupload add-on.

https://addons.mozilla.org/en-US/firefox/addon/2190
Please allow about:config item.


(In reply to comment #0)
> Now it is really irritating to send 5 photos though gmail/yahoo as attachment.
> when ever I touch textbox on file control
> the F### the file picker pops up.
> my picture folders have more than 100 pics
> dont ask me to scroll and choose each one.
> allow me to select first file then copy/paste/edit rest...
> because photos taken on same week are off by 1/2 digits.

Why can't you click, hit Ctrl-V/Paste when the file picker pops up to paste the path in, and hit enter to confirm?  The file picker should allow you to type in a path.  There should be no change in your workflow here, except maybe hitting Enter instead of Tab; you don't have to use the GUI file browser if you prefer typing.  It works for me very nicely on GNOME, except that the file picker has a default value that's not automatically selected (so it isn't cleared when I hit Ctrl-V, I have to hit Ctrl-A or Shift-End first).

> We dont need bug 258875 for security reasons
> you can solve all <input type=file> security issue by following two rule.
> 1. dont allow script to change focus to and from <input type=file>
> 2. dont allow script to read keyboard events on <input type=file>
>    (onContentChange event is ok)

This is wrong, as you would know if you had actually read all the discussion about implementing this.  Look at this example:

https://bugzilla.mozilla.org/attachment.cgi?id=17860

The user is (pretty reliably) tricked into copying and pasting a dangerous filename into a file upload form, thinking it's a password form.  With some scripting on onContentChange or whatever, some convincing asterisks could be overlaid on the password picker using absolute positioning, obscuring the fact that you're inputting a sensitive file name.  There's no way to avoid this without making it *very clear* to even non-tech-savvy users that you're specifying a file to upload.
Just posting to add my support for this as well - and to cross readers of this bug over to the discussion in bug 431098 which has inadvertently become a discussion about this very topic (re-enabling or otherwise correcting the problem caused by "fixing" bug 258875).

Years (which have most likely boiled down to a total of hours) of discussion or otherwise, this current solution is simply unacceptable for day to day use. It's affecting many more people negatively before it's even hit a release, than the original problem has in all the years a web browser has been exhibiting its current file picker behavior.
Do you have any actual data to support that last assertion?  If you do have data on how much (or whether) this problem has been exploited, I'd love to see it.
Since you asked so directly... I guess I have no choice but to once again reply to the whole list.

Well, yeah, in a sort of way, I do have actual data to support that.

Number of times I've even encountered a site that exploits the pastehax: 1 (and that was the proof of concept page)
Number of times I've encountered problems caused by Firefox's "exploit patch": about 7 or 8 and counting...

And the first figure includes all the time before the "exploit patch" even existed, effectively making the figure even further diminished in value.
That's not data in the sense that's needed here, for two reasons:

1) That's your personal experience, not the blanket "true for everyone"
   statement you made.  Clearly personal experience will vary widely depending
   on the sites you visit and on personal behavior differences (e.g. I suspect
   you don't click random links in e-mail from people you don't know).  What's
   needed is some estimate of the number of people affected by both issues,
   not whether you personally are affected by them.  The evidence you have
   provided so far is that one number is at least 0 and one is at least 1.
   That's not much to work with.
2) I see no indication that you accurately measured the number of sites that
   have tried to steal files from you.  You have accurately measured the number
   that tried to do that and then told you about it.  Do you seriously think a
   site that was using a setup like this to steal users' files for real would
   _advertise_ that fact?  That is to say, even your "at least 0" might well be
   "at least 1".  You have no data to the contrary.
Oh, and I urge you to either take a good statistics class (if you were being serious) or to advertise your jokes better (if that was a joke).  Or to not argue disingenuously if that's what's going on here, of course, but I'm giving you the benefit of the doubt on that one.
I can't believe we're arguing about statistics and occurrence of the exploit.

JUST ADD AN OPTION TO DISABLE THE SECURITY "FEATURES"!

End discussion. Or at least my part.
Matt, you are the one who brought up statistics and occurrences in comment 6, last sentence.  I'm not sure what you have a hard time believing...

For the rest, please stop shouting.  In fact, I strongly urge you to read <https://bugzilla.mozilla.org/etiquette.html> (esp. the "no obligation" section).  

To address your shouted demand, if you wanted to you could write an extension that would revert to the old behavior.  I'm not sure there's much reason to spend developer time on making it easier than that to shoot yourself in the foot.
...Wow guys.

Seriously, don't flame each other.  You guys are both very intelligent young (or old) men.

Let's just try to get an option to Disable the Security feature alright?  It's a good temporary fix to a good phish.  But it's madly inconvenient.

Madly.

You guys sound like the silly parts of the internet.  Pretentious Over-zealous fat men in their mother's basement.  Chill.
(In reply to comment #6)
> Years (which have most likely boiled down to a total of hours) of discussion or
> otherwise, this current solution is simply unacceptable for day to day use.
> It's affecting many more people negatively before it's even hit a release, than
> the original problem has in all the years a web browser has been exhibiting its
> current file picker behavior.

Could you describe any problem at all with the change that's not fixable by any means short of reverting to Fx2 behavior?  As far as I can see, there are some implementation details that need to be fixed and nothing more.  Or is your argument that it should be reverted because it's not worth developer effort to fix it so that it's as polished as the previous behavior?

(In reply to comment #13)
> Let's just try to get an option to Disable the Security feature alright?  It's
> a good temporary fix to a good phish.  But it's madly inconvenient.
> 
> Madly.

Again, could you describe in what ways it's inconvenient?  Specific bugs should be filed against each problem with the new behavior (and several have already been filed).  There are probably ways of fixing all issues that arise without having to back out the change.
(In reply to comment #14)
> Could you describe any problem at all with the change that's not fixable by any
> means short of reverting to Fx2 behavior?

Comment 0 contains such an example.

(In reply to comment #5)
> Why can't you click, hit Ctrl-V/Paste when the file picker pops up to paste the
> path in, and hit enter to confirm?  The file picker should allow you to type in
> a path.

First, that's a lot more steps to take.  It doesn't matter if you are just doing one or two files, but the use case is specifically about doing this with many files, where otherwise small inconveniences add up to become big inconveniences.  There is also latency in popping up the file picker as the dialog is populated, icons are drawn, etc. (and in Windows, you can even be subject to the problem where busy or inaccessible drives will block the dialog for a long time before Explorer finally gives up); once again, it's a small latency, but it adds up.

(In reply to comment #14)
> As far as I can see, there are some implementation details

Solving problems like clearing the input field would just be icing on the cake, and I don't think that should play a significant role in determining the usability cost of the new restrictions (and if the approach to make this an option is taken, then that problem won't even be solved here)

(In reply to comment #9)
> That's not data in the sense that's needed here

I think we're going down the wrong path by arguing about data, because data is not relevant here.  It really comes down to a question of cost vs. benefit, and the problem with that is that there is no objective way to measure it either quantity.  People's personal experiences differ based on their browsing habits and their usage patterns.  I will concede that for most use cases, the usability cost of the new restrictions is zero or close to zero, but for certain use cases, they are significant.  Likewise, the likelihood of someone ever encountering a malicious page (of any sort) also depends a lot on their browsing habits.  And finally, how different people weigh the relative importance of the risk of a security mishap against the value of usability can vary too.

Someone who is very paranoid might avoid driving on freeways while most people do not think that the increased risk of death associated with the higher speeds is worth the time lost by taking slower, but safer routes.  My personal opinion is that, like the freeway example, this is a case where the cost of security eclipses its marginal benefit.  But since that is just my personal opinion and since I concede that the usability cost here is probably very low for the majority of users, I don't think that backing out the change is the right thing to do.  But allowing users to decide for themselves what their personal cost-benefit equation comes out to is.  We already do this in many other areas: e.g., users are free to disable phishing protection, malware protection, and the restrictions on insecure addon updates.
Personally I think that the security benefit is necessary, however minimal the chance of running into a malicious site.  One could argue that almost all websites people visit don't have any exploits, but that doesn't mean Firefox should allow websites to pick any files they want off your hard drive.

And allowing people to pick whether they want security or not is fine, but that definitely sounds like extensions territory.

I think the problem here is that the UI is wrong for what it does now.  I personally hate the new behavior but I'm willing to accept that there's no other way to prevent the exploit.

That said, I think having the box the way it was in past releases of Firefox, yet not work the same way, is a horribly wrong UI choice.  I'd rather do what Safari does (it shows the file's basename and a "Browse"/"Cancel" button, no input field at all) than a box that makes you feel like you can type into it.

I think the ease of use of being able to tab through 10 input fields and paste in the filename can't really be regained.  For the latency (since I agree network drives and such are an annoying problem), an extension could change it to a text field prompt dialog with a browse button - seems a fairly simple solution.

-[Unknown]
(In reply to comment #16)
> And allowing people to pick whether they want security or not is fine
>
Why not?  It's one thing to enable the security by default.  It's quite another to enforce so absolutely.  Do you propose that all users should be forced to run anti-virus?  That all users should be forced to run a firewall?  TBH, that sounds rather Draconian.

> definitely sounds like extensions territory.
> 
I'm not sure that's possible in this particular case.

> That said, I think having the box the way it was in past releases of Firefox,
> yet not work the same way, is a horribly wrong UI choice.  I'd rather do what
> Safari does (it shows the file's basename and a "Browse"/"Cancel" button, no
> input field at all) than a box that makes you feel like you can type into it.
> 
That is a separate issue (bug 314365) and is not particularly relevant to this bug.
Personally, the new behavior was a problem for me.  I was running Kubuntu with an ATI card that had terrible drivers that took an obscene amount of time to load new windows.  This only took a few seconds, but that got annoying real fast.  I've fixed that problem since then, but it does point out that there are situations where it is desirable to turn annoying behaviors like this off, and there's no reason to outright refuse to allow this behavior.

So the question would seem to come down to whether it would be better off as an extension or an about:config option.  I don't know enough about creating either of these solutions to know which would be more ridiculous to implement, but I do know that having to go download an extension seems like a bigger pain that just changing an about:config setting.
(In reply to comment #17)
> That is a separate issue (bug 314365) and is not particularly relevant to this
> bug.
> 

It's related if it's causing this bug.  If the UI was changed so there was no even field, a lot less people would be experiencing this bug.  As is, the current UI is horrible - looks like you can edit, but you can't; impossible to deselect the file after selecting; impossible to see the full filename (and thus the part you probably care most about at the end); looks exactly like completely different previous UI.

Anyway, for extensions - I don't know off hand exactly how to write an extension that would affect form fields (I would assume it would have to mess with XBL which I've never messed with in an extension before except using it.)  Boris Zbarsky said an extension can address this problem so I believe him.  He knows his stuff.

An about:config setting has these pros/cons:
1. +Doesn't require an extension.
2. -Requires Mozilla's time (and not someone else's.)
3. -Increases complexity/maintenance probably moreso than the extension (as a separate thing.)
4. -Not quite as easy for the average user (if it's true that this is so noticeable) to install.
5. =Neither might be available for future releases.
6. +Easier to flip on and off (no restart) than an extension.

IMHO.

FWIW, I would be happy if users were forced to use a firewall.  If you don't want a firewall you should be knowledgeable enough to configure it to allow all ports IMHO.  Same with AV and I'm sorry if that's Draconian.  

Security is security and if you're not draconian you're not secure.  I've written and managed software that wasn't half as subject to security backlash as Firefox is, and absolutely support the improvement of security here for so many reasons.  Just because you wouldn't normally fall for it doesn't make it not a problem.

Still, "enforcing" is hardly being done here, config option or not.  I use an extension to monitor HTTP requests - is it "draconian" to "enforce" that HTTP requests aren't visible to me without an extension or proxy?  Hardly.

-[Unknown]
Well, to lay this to rest...

Extensions are hacks, plain and simple. A hack shouldn't be needed to give back lost functionality or to DISABLE so-called "security features". A hack is a way to do something that a developer refuses to implement or do, or cant, like IE Tab, NoScript, Page Saver, etc... extensions that "hack" around Firefox's limitations (like Nightly Tester Tools' extension compatibility override, RAMBack, ClearFileUploadFields, and especially OpenDownload) should just be integrated into Firefox as options already.

So-called "security" in Firefox is really badly managed. Right now it treats everyone like e-retards and holds your hand for pretty much everything. Some of these "features" can be disabled through about:config tweaks, but it should REALLY be made more accessible through the actual preferences pages - either that or a single unified "user.moron = false" setting. Having too many about:config settings just makes it impossible to find the useful ones amongst the hundreds of trivial settings. Having an extension is just unacceptable as a solution since it's just a way to hack around a bad programming decision.
(In reply to comment #19)
> 2. -Requires Mozilla's time (and not someone else's.)
>
If I can get assurances that the idea won't get WONTFIX'ed, I'd be happy give such a patch a shot.

> Security is security and if you're not draconian you're not secure.
>
I respectfully disagree.
(In reply to comment #20)
> Extensions are hacks, plain and simple. A hack shouldn't be needed to give back

https://addons.mozilla.org/en-US/firefox/addon/1843
https://addons.mozilla.org/en-US/firefox/addon/684
https://addons.mozilla.org/en-US/firefox/addon/60
https://addons.mozilla.org/en-US/firefox/addon/2464
https://addons.mozilla.org/en-US/firefox/addon/966
https://addons.mozilla.org/en-US/firefox/addon/5369
https://addons.mozilla.org/en-US/firefox/addon/216
https://addons.mozilla.org/en-US/firefox/addon/6622

Just to name a few addons which are hardly "hacks" and by no means fit your descriptions.  Maybe *you* use extensions that are hacks but that doesn't mean all are or that you should generalize as such.

You might feel that these feature should be built in, but I personally prefer them external - it's better, cleaner, and easier.

In general I disagree with your comments about security.  I personally find little need to change any of the security settings of Firefox as default, and I'm the sort who writes XML parsers and HTTP clients for fun.  Maybe that makes me a moron too.

(In reply to comment #21)
> > Security is security and if you're not draconian you're not secure.
> >
> I respectfully disagree.
> 

I've been on the receiving end of Secunia and Bugtraq reports for my projects (many of which were simply incorrect and I had to argue with the security vendors about, sigh) and they will eat you alive if you're not draconian about security.

A lot of people look at sites like that to determine "security" of software.  It's pretty much entirely wrong, but a lot of people do it, so alas.

-[Unknown]
(In reply to comment #17)
> I'm not sure that's possible in this particular case.

It should be.  One thought that comes to mind is to have the extension overlay the textfield with an anonymous text input and then set the file control value to the text the user types in, for example.


There's no reason an extension has to restore the old, insecure interaction style.  Here are some ideas that would enable interactions that are both safer and more efficient than the old style:

* Add a keyboard shortcut for "take the text in the clipboard, make sure it's a valid filename, and stick it in the nearest file upload control".

* Make the file pickers multi-select.  If you select multiple files, *remember* the additional files and fill them in as soon as additional file upload controls from the same site appear.

* Cause the GTK file picker to open with the "filename" field visible and focused.

* Make the file pickers multi-select.  If you select multiple files, upload them all to the site and hope it works. 

The existence of the last extension would be a great first step toward fixing bug 373866 and bug 63687 happen for *everyone*, as it would help shake out bugs in web server software and give us an idea of what bad things happen when users select multiple files with sites that aren't designed to handle it.

(In reply to comment #20)
> So-called "security" in Firefox is really badly managed. Right now it treats
> everyone like e-retards and holds your hand for pretty much everything.

I might agree that security is mismanaged in some cases: say, bug 327181 (trying to make dialogs scarier for something that 99.9% of the time is *not* malicious, which devalues security dialogs more than it improves security).  But in this case, the posted examples have made it clear that anyone could be pretty easily fooled into uploading arbitrary file paths from their computer, when they think they're just filling out a text field.  There may be alternative fixes, but it's definitely a problem that needs to be fixed, and this change decisively solved it -- with, unfortunately, some negative side effects, which may or may not be worth the fix.

But in any case, this particular fix has nothing to do with whether you're an e-retard.  Anyone could be exploited equally well by a malicious website.
Example :

I know this might be a little late but.  Simply put, I'm a web monkey for a company that isn't very advanced.  We have an eCommerce website where uploading a database does not work.  And we are forced to upload every picture and product individually.

Whenever I upload a product, I need to upload three sizes.  Thumbnail, Standard, and Enlarged.  So there are three boxes for three images.

I create these images using a Macros that separates each one into three different folders.  E S T, respectively.

The reason I use Copy and Paste is so that I can take the first one...

file/T/file.jpg

and then just paste it and change the Folder

file/T/file.jpg --> file/S/file.jpg

It makes my work a million times faster than --> DragnDrop or Browsing for the file.  It may seem completely benign to you, but when I have to upload 10 - 50 products in a day.  You want to cut every single step possible.

Imagine the difference between...

Browse --> Choose --> Copy
Paste --> Paste
Change File Directory --> Change File Directory
Submit.

And

Browse --> Go Up --> Change File Directory --> Choose
Browse --> Go Up --> Change File Directory --> Choose
Browse --> Go Up --> Change File Directory --> Choose
Submit

The current Firefox requires me to use mouse only.  Which takes longer than using keystrokes.  Like how you need to memorize keystrokes in Starcraft, keystrokes makes things faster, and allows you to move quicker.

Even if I create a new macros, that places files into the same folder with the file_T.jpg file_S.jpg file_E.jpg.  It would still require the use of a mouse, which would be slow and clunky.
(In reply to comment #26)
> Browse --> Go Up --> Change File Directory --> Choose
> Browse --> Go Up --> Change File Directory --> Choose
> Browse --> Go Up --> Change File Directory --> Choose

This is unnecessary; the file selection dialogs on all popular operating systems I've used allow you to paste a full file path.  That said, it's more work to initially copy the path now (since you can't really do so from the file/browse input field anymore easily.)

My suggestion would be to find the file using, for example, Windows Explorer, and copy its full path from there.  Then you can easily copy and paste that into the file selection dialogs, very similarly to how you were before.

-[Unknown]
Also the time it takes to open the file selection dialogs is to be mentioned.
(In reply to comment #27)
> My suggestion would be to find the file using, for example, Windows Explorer,
> and copy its full path from there.  Then you can easily copy and paste that
> into the file selection dialogs, very similarly to how you were before.

Since it's no longer possible to even select the text in the box without activating the file browse window, it's impossible to even copy the path name.

Along with the previously mentioned delay in opening the file browser. Has to be the least thought-out "security fix" in history.
I have to agree this is really not well thought out. The fix is clunky and highly annoying. There have been a lot of rational opinions expressed here (and some fairly emotional ones) but it's been met with mostly dismissal.

Simply allowing an about:config option to disable this feature - or better yet, a feature that can enable/disable the behavior on a per-domain basis, would eliminate all of the disagreement.

To me this is just a really ugly fix that causes more grief then it prevents. Several better solutions have been suggested and I think that it should be a high priority to implement something better in 3.0.1.


Well hey, whoa.  Slow down the horses here.

Calling it an ugly fix, there are ways it could have been a lot uglier.

Firefox did what it could to solve the problem temporarily, I highly doubt they were just going to leave it like this.  We're probably the first ones to find a problem with it, and have found a place to talk about it.

I'll just reiterate what everyone else has been saying. about:config option to disable.  Or feature to enable/disable per-domain.  That would be a perfect fix, it won't confuse new people, it wil be available to us.  And how difficult could it be to implement?

If the coding asks the File browser to open upon hitting a browse window.
You can just add an "IF statement" and be done with it.

(In reply to comment #27)
> (In reply to comment #26)
> > Browse --> Go Up --> Change File Directory --> Choose
> > Browse --> Go Up --> Change File Directory --> Choose
> > Browse --> Go Up --> Change File Directory --> Choose
> 
> This is unnecessary; the file selection dialogs on all popular operating
> systems I've used allow you to paste a full file path.  That said, it's more
> work to initially copy the path now (since you can't really do so from the
> file/browse input field anymore easily.)
> 
> My suggestion would be to find the file using, for example, Windows Explorer,
> and copy its full path from there.  Then you can easily copy and paste that
> into the file selection dialogs, very similarly to how you were before.
> 
> -[Unknown]
> 

You talk kind of funny.  I'm not even sure if you're agreeing with me or disagreeing with me.  There's only one thing I'll say about what you wrote though, and that is that you may not understand the problem.

We can't Paste anything in the File Browse Box, without activating File Browser.  Click --> Filebrowse Opens(Paste = No, and I am very sad) -Emo Tear-

---

Also, you were talking about Extensions not being Hacks.  This may be a Semantics error.  Hacks originally are not malicious ways to gain unrightful entry to one's computer or anything.  They're modifying or adding to a code.

Main Entry:
    hack·er Listen to the pronunciation of hacker
Pronunciation:
    \ˈha-kər\ 
Function:
    noun 
Date:
    14th century

1 : one that hacks
2 : a person who is inexperienced or unskilled at a particular activity <a tennis hacker>
3 : an expert at programming and solving problems with a computer
4 : a person who illegally gains access to and sometimes tampers with information in a computer system

Seriously.  Let's not trying to cut anyone down around here okay?  We're all semi or complete intellectuals here.  Which is a nice way of saying we're people who spend far too much time on the computer.

Far.  Too much time.

Let's try to discuss what 'we' can do about this?  Can we ask for an extension?  or possibly is there someway we can bring more attention to this to the Firefox team?
I don't think it's quite as simple as a single if statement. Actually there are a lot of complex issues involved in this fix. If I had even the slightest clue about all of the issues I would already have submitted a patch to enable the about:config option (not that it would be accepted but at least there would be a patch to argue over) - I really don't think it's that simple but I would be happy to be told otherwise.
(In reply to comment #32)
> You talk kind of funny.  I'm not even sure if you're agreeing with me or
> disagreeing with me.  There's only one thing I'll say about what you wrote
> though, and that is that you may not understand the problem.
> 
> We can't Paste anything in the File Browse Box, without activating File
> Browser.  Click --> Filebrowse Opens(Paste = No, and I am very sad) -Emo Tear-

Erm, sorry if the way I word things is strange to you.  I'm simply trying to help you.

Here are the steps:

1. Navigate to the file input/browse field, and click on it or tab to it and press space.
2. Operating system file selection dialog opens.
3. Inside the dialog, press Ctrl-V, Apple-V, or whatever pasting shortcut you like (I'm used to Shift-Insert myself.)
4. Using the arrow or backspace keys, correct the path.
5. You pretty much have the same deal as you had before (it's just slower.)

Indeed; this entire process can be done entirely without using the mouse.

> Also, you were talking about Extensions not being Hacks.  This may be a
> Semantics error.  Hacks originally are not malicious ways to gain unrightful
> entry to one's computer or anything.  They're modifying or adding to a code.

In this context, I interpreted "hacks" to mean "dirty fixes" which is a common use of the term in programming (whereas hacker has a positive connotation, except in common usage.)  In other words, to create a hack is to paper over a problem in an undesirable, and likely temporary, way - I showed examples of great and popular extensions that are perfectly fine the way they are.

I think Jesse Ruderman gave some great ideas on how to properly fix this bug.  I suspect time is better spent on making a clean UI for multiple files (that applies well to single files as well), which would solve this bug and many others.

That said, as a web developer and someone who has put code on some rather popular websites, I suggest that multiple file upload really must be an opt-in thing (e.g. min=, max= as per whatwg) and if it were just applied to input fields that didn't instruct otherwise it would never work (causing yet more broken UI!)

-[Unknown]
I would like to once again ask everyone to read <https://bugzilla.mozilla.org/etiquette.html>.

This bug now has 35 comments, most of them not helpful to getting anything fixed, but instead driving away developers (who don't need the extra more or less content-less e-mail) and making it harder to figure out what's going on with this bug.

If you think this should be fixed, vote for it.  If you feel that someone needs convincing that it needs to be fixed, the bug is NOT the right forum for that, since at this point the only people reading it are those who either want the bug fixed or those who read all form controls bugs.  And frankly, I'm about to stop doing the latter, because of the volume of useless spam this bug generates.
If you don't want the additional spam, stop trying to nullify the severity of the problem at hand and trolling for more people (who are in the majority) to come in and reiterate how much of a problem it truly is.

There are no developers here at the moment (at least that I can see - none have commented on providing a solution at least), so that effectively leaves none to scare off. The point is that we want someone to JOIN this bug and actually fix it. Hence the discussion.

At this moment all you're doing is trolling for more people to argue in this topic. Obviously your post was not the last someone would have to say on the subject, so you were obviously expecting someone to come in and tell you how ridiculous your statements are. Trolling.

So please... if you disagree with this (for some unknown reason), stop posting. Find another bug to discuss if this isn't your flavor. Meanwhile, let the people who actually post statements with some content do the discussing. Your content-less "stop discussing this issue, people!" posts are quite annoying.

My email inbox thanks you.
> There are no developers here at the moment

That's true now, for sure.  But for what it's worth, I'm the developer who generally works on form controls.  Too bad this bug is too much pain to be worth following.
Since a few people had mentioned to me after posting...

It sure would have helped if Bugzilla actually indicated that you were a developer yourself. It appeared that you were just another Googler that found this bug and doesn't like reading about it (in other words, I interpreted "waaaaah", instead of a developer suggesting that people STFU and let them work on it). Hence my return "STFU". Sorry about that.

But seriously though, if you're going to abandon a severe bug because someone didn't realize that you were a developer posting in stealth mode... well, that's kind of irresponsible if I may say so. This bug just does irritate me that much, and if this control is left the way it is for the final release, needless to say there will be a huge public outcry (if there's this much from just beta testing).

If it's useful discussion that would entice you to stay with this bug and help fix it, here's a workable solution that incorporates what I understand to be everyone's concerns:
Turn the file control into a single dynamic-text button. When there is no file selected, the text is "(File) Browse..." or the like. When a file is selected, the filename is the button's name (perhaps with a "(File)" prefix). Make it so the button can be right-clicked with four entries - "Clear", "Manual", "Copy", and "Paste". Paste functionality will still be there but can't be exploited because it doesn't appear to be a text box (and still can't be controlled by scripts, i.e. pasting into a real textbox then filling in the file control field with that value). "Manual" would present a text entry box like editing an about:config value, where you can paste, then edit, the file path. "Copy" would copy the complete path of the selected file to the clipboard, to assist with OSes that don't make copying paths easy (like Windows).

Or just make the current functionality an about:config item, which appears to be about as likely to pass as Ron Paul becoming the next president. (heh)
(even better, but even less likely, would be to overhaul all these annoying "security" options into the main "Options" system under "security"!)

Lots of solutions here and in the past posts. I just hope one of them actually makes it before the final gets released...
> Lots of solutions here and in the past posts. I just hope one of them actually
> makes it before the final gets released...

Considering that the final release is tomorrow, that's not going to happen.  I would assume everything is far too committed at this point to rush in even an extremely minor fix.

The dynamic text button is the best compromise reached so far, considering it doesn't confuse people with a fake text input.  Either that or gray out the input box or something so it doesn't look like you can edit it.

Still, that doesn't solve the issue many people have raised concerning the opening of new windows.  Which would point to either an about:config option, a new security settings panel, or a security management extension.  Or an option someone hasn't thought of yet.

At this point, what I consider to be the major problem is not that the window itself opens, but that we confuse people into thinking they can input text.  That needs to be redone as soon as possible.  I spent several minutes trying to figure out what to do, and I think we could expect a lot of other people to do the same.
I think the reasoning behind this "security hole" is really ridiculous. It's like saying since a phishing site can use the password input box to trick the user entering his bank account password, so the input box should be disabled. or because some site can trick users to download a trojan disguised as a good utility, so file download should be disabled.

I think Firefox 3 added all those anti-phishing and anti-malware features just because of situations like this?

And last but definitely not the least, this "security fix" can be easily bypassed with the use of flash controls, java applet, silverlight, etc. 

Thus I'd say this got to be the most brain-dead "security fix" of all time >_>
(In reply to comment #38)
> 
> Lots of solutions here and in the past posts. I just hope one of them actually
> makes it before the final gets released...
> 
I don't know whether these are mentioned already or not, but this is what I propose to solve the "malicious exploit" problem instead of disabling the input box :

1. restrict the styling of the file input control, for example having an invisible file input control should not be allowed from the first place.

and/or 

2. put a non-styleable grey text of "upload file here" over the input box, so despite how the file input is styled, there will always be a grey "upload file here" prompt over the input box.

That should solve the proposed "security hole" without suddenly drastically changing the user's expect behavior of the file input. Albeit naturally the flash control/java applet/silverlight will still have this security hole, and a truly malicious website can easily utilize those.
a couple more random brain-storming ideas :

show a warning (pop-up dialog or, better, a drop-down bar) when a page contains file input controls, to say "beware that this page contains forms that will upload your files to a remote server", and you can select to stop warning for this site again.

or 

show a warning (pop-up dialog or, better, a drop-down bar) when you try submit a form that contains file input controls, saying "this form will submit your files to a remote server", and you can select to continue, and/or to stop warning from this site again.

And either way, I don't think about:config option is sufficient, I think there should be an option in the security settings to turn this "security feature" on/off, since it's a very big change altering the user's habit when browsing the web. Since the anti-phishing/anti-malware feature can be turned off from the security settings, there's no reason why this "security feature" shouldn't earn a setting in the security options.
Konqueror have had an inteligent way of dealing with this exploit since many years ago: when you click "send", it asks you if you really want to upload the files.

If we want to avoid this exploit, I think this would be the way to go. The only comments I've read around the internet about this new "feature" were complains and insults to Firefox developers.

Everybody wants at least a configurable option, or the hability to change the "Browse" button to "Clear", in order to clear the field, which right now is completely impossible, and in some web pages is required, making browsing them with the new Firefox much more unconfortable than with previous versions.
(In reply to comment #29)
> Since it's no longer possible to even select the text in the box without
> activating the file browse window, it's impossible to even copy the path name.
>

Its possible to select the text without activating the window:

Click and drag the mouse from left to the right side and release the mouse button outside the field, if you release the mouse outside, the filepicker wont be activated.

The other is to click on the beginning and release the mouse outside and then use the arrow keys and shift to select what you want. Its also possible to select different parts of the path using multiple text selection (with ctrl) introduced in fx3, of course you have to release the mouse outside the field every time.
> (In reply to comment #29)
> > Since it's no longer possible to even select the text in the box without
> > activating the file browse window, it's impossible to even copy the path name.
> >

> Its possible to select the text without activating the window:

> Click and drag the mouse from left to the right side and release the mouse
> button outside the field, if you release the mouse outside, the filepicker wont
> be activated.

> The other is to click on the beginning and release the mouse outside and then
> use the arrow keys and shift to select what you want. Its also possible to
> select different parts of the path using multiple text selection (with ctrl)
> introduced in fx3, of course you have to release the mouse outside the field
> every time.

But how obvious and intuitive is this solution?  Even if it really is possible, it doesn't conform with how most people would expect to be able to select the text and is therefore virtually useless.

If you actually go and read through the entirety of both bug 258875 and this one, you should be able to tell exactly why we ended up with the solution that we did and why that solution sucks.  We've ended up with an unintuitive and cumbersome interface.  This discussion is getting circular and it's clear we should do one of two things:
1) Just get rid of the file input box to end all the confusion (bug 258875, comment #10, 3rd bullet) and add a method to extract the path, like a copy button
2) Design a completely new interface which solves this problem and allows Firefox to comply with multiple file uploads as suggested in comment #24 and the HTML 4.01 specification, section 17.13.2.
Im worried more about that when there is already selected file, there is no way to delete the value, e.g. if there are 3 upload fields and i select 3 files, but then for some reason i want to upload only 2...

Even when the page is reloaded the value is there. Unless ctrl+f5 or hit enter on the urlbar and start again i dont see another variant. There might be a problem if the filled form is long.
Ok, so this thread has been going since '07, and there has been no movement at all. and the feature in FF 3.0 sucks!

Once again, could we please allow direct input of file name into file upload controls. You have no idea how much this has slowed me down and I am sticking to FF 2.x until this is solved. I understand security concerns, but one person's perceived security issue is another person's liberty! Just ask the folks in D.C.! If you must turn this silly feature on, fine, but can we change it user.js or wherever?

Thanks
(In reply to comment #46)
> Im worried more about that when there is already selected file, there is no way
> to delete the value

Ditto, this is my real problem with the feature.  I work with a screen everyday where I may or may-not be uploading a new file.  I also need to enter in a bunch of settings at the same time.  If I make an error and need to remove the selected file I don't want to have to perform a reload of the page and then have to re-enter all my settings too.  Select All -> delete, I'm done.

(In reply to comment #44)
> (In reply to comment #29)
> > Since it's no longer possible to even select the text in the box without
> > activating the file browse window, it's impossible to even copy the path name.
> >
> 
> Its possible to select the text without activating the window:
> 
> Click and drag the mouse from left to the right side and release the mouse
> button outside the field, if you release the mouse outside, the filepicker wont
> be activated.
> 
> The other is to click on the beginning and release the mouse outside and then
> use the arrow keys and shift to select what you want. Its also possible to
> select different parts of the path using multiple text selection (with ctrl)
> introduced in fx3, of course you have to release the mouse outside the field
> every time.
> 

This is a joke right.  You are relying on the dexterity of the user to perform an action that should be right-click->select all, right-click->copy.  On top of that, the release point counts!  And even then its unreliable that the file-open dialog won't popup.

The fix is an about:config setting.  The average grandma or parent isn't going to turn it off.  The average site that suggests the work around is going to mention the original intention of the feature. And the average advanced user that does go out of their way to turn this feature off is going to be more than aware of the hackers trying to steal their files.

Look Mozilla, I'm a big boy now and I can surf the web all-by-my-self.  If you insist on trying to add protections by default, that get in my way, at least give me a tool to turn them off if I'm really really really sure.  Thank goodness there is IE Tab or else I'd never get my work done.


Deleting the selected file is bug 431098.  It will be fixed, no question.

> the average advanced user that does go out of their way to turn this feature
> off is going to be more than aware of the hackers trying to steal their files.

I'm a pretty advanced user, and I would have no idea that some of the file-stealing exploits we fixed with the no-typing-in-the-textbox changed were active...  Note that malicious script is likely to be present on any page that has ads: ad servers get hacked on a pretty regular basis.
> I'm a pretty advanced user, and I would have no idea that some of the
> file-stealing exploits we fixed with the no-typing-in-the-textbox changed were
> active...

And konqueror had that problem fixed years ago with the receive-a-warning-when-the-page-tries-to-upload-a-file feature. I considered it a little bit annoying the first time I saw it, but is definitely less annoying than FF3 method.
That's a lot of implementation complexity and code for what is very much an edge case (because such a dialog is NOT an acceptable default behavior).
(In reply to comment #49)
> 
> I'm a pretty advanced user, and I would have no idea that some of the
> file-stealing exploits we fixed with the no-typing-in-the-textbox changed were
> active...  Note that malicious script is likely to be present on any page that
> has ads: ad servers get hacked on a pretty regular basis.
> 

Then why Firefox allow people to turn off the anti-phishing and anti-malware features? by your reasoning, those should be enforced more than this file upload "exploit". 

(In reply to comment #51)
> That's a lot of implementation complexity and code for what is very much an
> edge case (because such a dialog is NOT an acceptable default behavior).
> 

Geeze, it's no more "unacceptable" than Firefox popping up a dialog box the first time a secure site send data to non-secure site, etc. Also I'd say it's much MORE acceptable than the current "disable text input outright" default behavior. Also you can have options like "don't show for this site again" and "don't show again" checkbox on the dialog, so next time you upload files to this site (which you already fully aware of it being a file upload), it won't prompt again.

As for implementation complexity, I don't think it's any more complex to implement than the current confusing "click a text input box and a file browser popup" implementation.
One of many serious drawbacks to this new behavior for file uploads:

After I choose a file to upload, I am no longer able to clear the text box if I decide I'd rather leave it blank (and not upload a file at all) when I submit the form.  A file upload may well be optional in an html form.  This is like having a checkbox that once checked cannot be unchecked.

It is simply not acceptable to cripple such basic, standard, and well-established user functionality as being able to enter and/or edit text in a file upload form input.

comment #49:
> Deleting the selected file is bug 431098.  It will be fixed, no question.

comment #35:
> I would like to once again ask everyone to read
> <https://bugzilla.mozilla.org/etiquette.html>.
>
> This bug now has 35 comments, most of them not helpful to getting anything
> fixed, but instead driving away developers (who don't need the extra more or
> less content-less e-mail) and making it harder to figure out what's going on
> with this bug.
>
> If you think this should be fixed, vote for it.  If you feel that someone needs
> convincing that it needs to be fixed, the bug is NOT the right forum for that,
> since at this point the only people reading it are those who either want the
> bug fixed or those who read all form controls bugs.
Proposed fix:
Return old function of Firefoxes past. Instead of restricting the file upload textbox, display a small picture aligned to the left side of the box. The picture would just be something simple, like a folder or some text reading "File Upload". Upon clicking the textbox, said picture would disappear and input would be allowed (this would only require one click, not a click to remove the picture and another to select the textbox).
Not only would this warn users of hidden file upload boxes, it would cease all trouble that the "security fix" caused.

While programming of such a feature may or may not be difficult, I believe that it would solve complaints from both sides of the argument.
I don't see how that helps the hidden file upload box case.
RE: I don't see how that helps the hidden file upload box case.

Why not simply pop up a dialog box, *when the user clicks the submit button*, asking, "Are you sure you want to upload the following files to http://www.example.com/upload.php?blahblahblah ?"

That might be a bit technical for some users, but you could make the domain name part of the displayed url strongly emphasized so that people aren't confused by, e.g. a form that posts to:

http://reputable-site.example.com@www.evil-phishers.net/blahblahblah
                                  *********************

Yes, this might make it one extra step to submit a form that uploads files, but it should be even more secure than the currently implemented solution, and it would let us enter text directly into the file upload inputs if we wish.

Are there any disadvantages to such a scheme that I am unaware of?

Justin, _please_ read this bug.  All of it.  All the comments.  Then please read up on some actual user research in terms of how users react to dialogs.
The problem as I see it is mainly that the old look has been preserved although the functionality is completely different. Losing the ability to paste paths is very irritating to me, but nowhere near as irritating as a file browser jumping up at me when I click a standard text field.

I am not saying it's worth the risk to just go with the old upload box, but the temporary fix should have removed the text box entirely and went with a bigger button or something. As it works now, it simply feels like a broken file upload function. Very embarrassing for Firefox as a product since file uploads are so common.

I really don't agree that it's up to the operating system to make the file selection convenient. Let's remind ourselves that 90% are still using Microsoft Windows. Why not simply start discussing a new built in file upload functionality which fixes the security issues but is as powerful and convenient as the old one?
I also vote for at least an about:config option. This way only "advanced" users will get the old "unsafe" behaviour and the standard would be as safe as it is now. 

BTW I also miss the _quick_ copy&paste of file paths of FF 2.0
>1. dont allow script to change focus to and from <input type=file>
Why this have done? Don't think that it's a good idea to block focus method for input event if it's file type. Qestion is, how could I make it work in short time? 

As for manual writing file path: I think that it would be cool if textbox with file name will never get focus. So you tap tab in form and get to file field. You have focus on button to open dialog but instead of hitting enter you could hit ctrl+enter (alt+enter or something...) and only then you get focus in textbox where you show your skill in typewriting. Validation for file presence would be great. 

P.S.: This question is important to me because of wide using this type of field in projets and corporate standardization on firefox. From my point of view users who work with that, often even don't know the name of the folder where their upload file could be. As for me I work mainly on keyboard but using dialog to choose file don't upset me much.

Would you at least tell me if there's any way of compiling firefox so that direct input is allowed again? Maybe I can patch --reverse the patches that fixed this "bug"? Could you tell me the reference to those patches?

If you won't fix this at least I would like to have it working as it used to work in my machine, and I'm sure other advanced users would enjoy it as well.
I still use FF2 and wait for this fix, had better a control item in about:config
I agree with comment 62. It looks like a text field but you can't paste into it and clicking on it brings up a dialog.  In that dialog that pops up I can paste text, so why stop me from pasting it directly where I need it?  Another undesirable side effect is that using the dialog changes the 'current directory' relative to the dialog.  Before this change I could type or paste any location I want and using the Browse button would bring up the dialog conveniently in the same location that it was last opened in. Now I'm endlessly having to switch directories because it forces me to use the dialog.
Making a control behave like a different control is not a proper way to work around a security problem, it just makes an additional security problem. What becomes of security if uses cannot trust controls to do what their supposed to? Soon, (•)No ratio options will mean [Spam me], [No thank you] buttons will be [X] **** mail on me daily, and clicking text boxes will mean "data mine my hard drive". And when people complain, the spammers will say "We are simply following the standards set by the web community, such as the Mozilla Project"

This is like the "We Say So" **** that comes from both ends of the M$. Don't fix it, make another problem to hide it. Sometimes I want to take security risks so _I_can_get_things_done_.

At least remove the [Browse]/[Upload] button as it is now redundant _and_deceptive_. Until then, I'm testing Google Chrome, if it has this feature too (and it should, if this feature really is necessary) then I'm going back to FF2.
All I wanted to do was type a simple /tmp/a into the input box, but no, I must be swung into the click/quiz/whizzo browse system.
My first issue was for every picture I have to scroll thru 100s of pictures in the dir.
Dojo is trying to solve it using flash and multi-file upload
https://user.sitepen.com/~mwilcox/dojotoolkit/demos/uploader/demo.html?multiMode
http://www.sitepen.com/blog/2008/09/02/the-dojo-toolkit-multi-file-uploader/
This is a show stopper for me.  I have to upload about 200 pictures in a session and (comment #70) I too have to scroll through 100's of photos to select them whilst having to mentally which image I am looking for in the sequence.  

I was in the habit of copying and pasting, editing ranges of names in a simple non thinking way, but this change has made this a much slower, RSI inducing activity.

I have read the original bug fix for this feature and many comments about this change.  People seem to forget that this is a tool used by users.  Most of the dismissive comments are made by people that aren't affected by the change because they don't use this functionality to any serious degree.  

I think of firefox as a tool and used it because it had advantages over other tools of the same kind.  This change, along with improvements in other browsers, means that nearly all of the alternative tools are now better for me.  Dont get me wrong I like firefox, but I now am of the opinion of comment #68 and will either go back to FF2, run multiple browsers or change completely.  FF2 cant be a viable option as it will lose all support and have no new features.   

Firefox will silently lose a lot of users as a consequence of this change.
I just wanted to add.
At first, I thought this was simply a bug, but to learn Mozilla decided to do this intentionally... I can't believe it.  I'm all for security, but please don't throw standards out of the window and do what You think is best.

As someone else has stated, please don't start down the road of a browser we all demised, or else Firefox will end up just like it.
we can all just go back to Firefox 2. Let Mozilla blaze a Firefox 3 fronter with shoot'em'all gunfighter style fixes. When they get civilized and arrive a sensible solution, then we can all settle with ff3.

for many reasons, including the ff3 file bug, get ubuntu, <ubuntu.com>. Even though the latest ubuntu comes with ff3, there is also a community maintained version of firefox 2 available to add to your desktop (with no file text field == button click bug). An advanced package manager like adept-manager, will let you remove firefox-3.0 (or firefox) and install firefox-2 with a few clicks. It can also be done simply from the command line 
[code]sudo apt-get remove firefox firefox-3.0
sudo apt-get update && apt-get install firefox-2[/code]

bye bye file browse bug
Anyone know of a greasemonkey hack to break this behavior?
I don't think you can get the full path with Greasemonkey.  Greasemonkey scripts run with the privilege of the page, plus a few extra functions, but "give me the full path of this file upload control" isn't one of those extra functions.
Was not looking for something to upload with but would break the behavior by overriding the attribute that firefox see's for the file upload text area.
The current method is completely unintuitive. Currently the easiest way to remove a file from the upload field is to reload the whole page. Surely there should be a better way to go about this.
There must be a way to write a firefox extension which returns the old behavior, maybe even add some new functionality in the process... It seems that most people who are hurt by this change are doing massive uploads with multiple sequential filenames. This sounds like a problem in need of automation.

Anyone interested in helping with such an extension?
As a web developer I can say the option "make the element always visible" is not viable. There are hundreds of ways to obscure an element of user interface and you just can't find them all. Place the field in a 1px x 1px iframe, give it a big negative left margin, put an absolutely positioned element on top of it, shift elements around it as the page scrolls so that it's always outside the viewport.

The attacker can modify the clipboard, then trick the user into focusing a partially obscured element, then press ctrl-V, so stripping the element of JS privileges is not viable either.

A solution that would not be esthetically pleasing but likely very viable, providing almost 100% of the original functionality, making the path input very obvious and very immune to external tampering would be to pop up a Prompt type modal window upon focusing the text entry. It can provide the standard copy&paste features, it is just one keystroke/click (enter/OK) longer, and AFAIK while a modal dialog window like Prompt is open, the caller document can't tamper with the content.

All other than click methods of focus (tab, .focus() etc) could go only to the "Browse" button - that's the current behavior, and you can't distinctly focus two different parts of one element with Javascript anyway. Calling the prompt would require actual click (with a possible special keystroke alternative for advanced users) so the hate and loathing of javascript opening modal windows against your would would be mitigated.
> The attacker can modify the clipboard

Actually, we consider the ability to do that a security bug and tend to fix it.  So no, he can't do that.

> would be to pop up a Prompt type modal window upon focusing the text entry

How is that different from the current approach of putting up a filepicker modal window?  The number of keystrokes/clicks?  On Mac and Linux you can enter filenames in the filepicker after one keystroke; not sure about Windows.
>How is that different from the current approach of putting up a filepicker modal window?

You can actually clear the prompt. On windows, you MUST pick an existing file in the filepicker - once a filename is chosen, there's no way to clear it.
Clearing the file input is a separate bug, for what it's worth.  It's filed, and rather unrelated to this one (in that it can be fixed without allowing direct filename input).
Also, it's a bit tricky to copy the absolute filepath from one input field to
another. If you select the filepath, the picker pops up after mouse up (you
can't get the absolute filepath from the picker), you have to cancel it, copy
the absolute filename, and open the next one. If the full path was displayed in the modal prompt, it would be easier. On ubuntu, you don't even get the original filename in the picker (on windows, you do).
Have you considered filing a bug on the default name not being there on ubuntu?  That just looks like a bug in the (Mozilla GTK2) filepicker code to me: it only uses the filename layout provides if doing a save operation.

Let's fix the bugs we have instead of adding ways to work around them, eh?  ;)
I filed bug 472487 for the Mac filepicker and bug 472488 for the Linux one.
I fell disappointed when I see that Firefox, being a leading open-source project, ignores wishes of users. I don't see what I can myself do to help with this situation. Still I would like to ask the developers responsible for this situation, to stop for a moment and ask themselves a simple question: why do you work on Firefox? Isn't it positive estimation of people who use it, and who tell others to use it, that ultimately validates the whole work? Apologies for an off-topic.
We can't help if it users have self-contradictory wishes (e.g. being secure but also being able to do whatever they want).

I'm also not sure when filing bugs on issues people bring up and fixing them (e.g. comment 89) became "ignoring wishes of users".  Maybe in your alternate reality...
Boris, I do appreciate your work, but do not appreciate your disrespect. Please try to restrain yourself to not making personal statements, this is impolite.
> Have you considered filing a bug on the default name not being there on ubuntu?

I didn't think it was a bug, I though that it was just the way the GTK filepicker works... But it's not just an issue of the filename being there or not, but the ability to select the whole absolute path as presented in the form (and this affects windows as well). I've filed bug 472505.
Boris, it's very much ignoring the wishes of users to sacrifice convenience for security when the users desire both. It's likely that there are solutions where both are obtainable. They are not mutually exclusive, especially to the point of having security gun down convenience.
As it is, violating the status quo to make things more difficult (whether or not it's more secure) is going to lead to many complaints, such as the ones in this thread.
Not that we haven't already beaten this topic to death, but is there a good reason why we can't just create an about:config option which enables/disables direct text input of file names?

The only valid argument I can find is Jesse Ruderman's argument on bug 258875 that a person shouldn't be able to choose to expose themselves to a vulnerability, but I personally disagree with this.

We've already got several about:config options for small things like disabling warning boxes (security.warn_*) and larger things like java & javascript, so the principle that you shouldn't be able to toggle a security feature doesn't really hold up either.
My only issue with this is that it modifies the whole "last folder accessed" of the browser and overall, considering that I usually upload files from all over my system, in opposition to downloading files to a specific set of folders, means that every time I upload a file, when I go to download a file, I usually have to spend several minutes navigating BACK to my download folders.
Uploads and downloads should have separate "last-used folder" memory.  If that's not the case, please file  a new bug report.
Downloads use the value of the browser.download.lastDir preference, falling back on browser.download.dir preference, and the userDownloadsDirectory in that order.

None of those values are changed by anything involving form controls.

Of course if you have extensions installed that mess with this stuff that might be different.  Do please file a bug if you can reproduce your problem in safe mode, and please cc me on it.
So, summing up the current problems resulting from current solution...
1. inability to paste a path easily (mitigated by ability to paste path directly into the file input, still not intuitive - many users don't know it)
2. inability to copy current full path, and/or quickly edit it (increase number by one?) (unsolved)
3. inability to empty the field (unsolved)
4. extra time required to draw the dialog (unsolved, marginal) and use it (unsolved, not very significant)
5. confusing function/reaction (text field which you can't edit) (unfixed)

The "prompt" method would solve 1, 2, 3, and partially solve 4 (much "lighter" dialog) and 5 (still not the same behavior, but a much closer equivalent).

Did I miss any points?
I am going to post a request for feature: file path expansion.
I used to prepare the file path at the shell where the path expands by pressing tab. Then I copied the file from the Xterm into the Web form. But direct support of tab-expansion would be great!
This new browser behavior completely defeats the use case of multiple file upload where path paste-ins are used.  In the use case I am using right now, I am aware I can press enter and spawn the file chooser, then paste.  Don't the developers consider what if the path is UNC and the directory has a large number of files.  I guess they like us to see the flashlight.  My entire purpose of pasting in the path and typing the sequential file names is to avoid the time hit caused by the file chooser.  This behavior is so bad I must use a different browser so I end up less secure than I started.
Explain to me.. If I browse and take the time hit of the file chooser, and I end up with the UNC path in the upload field I cannot edit.  How is this more secure ?
#102 "If I browse and take the time hit of the file chooser, and I
end up with the UNC path in the upload field I cannot edit.  How is this more
secure ?"

You enter/paste the path into a big, obnoxious, unmistakable file selector, being fully aware of the fact what you just did. As opposed to typing/pasting random text and having its chosen pieces land in an obscured, invisible, editable file name entry field. There are currently no reliable ways to keep a text entry field always visible other than a separate dialog window, like the file selector.
Hi all, I am also frustrated by the file selector.

If there was a security problem, why not popping up a yes-no confirmation dialog with a security warning. This should pop up  when the user places the text cursor into the <input type="file"/> for the first time of the current Firefox session.

As a medical doctor I must warn from the danger of
 - multiple strain injury due to excessive mouse usage
 - Hypertension and gastric ulceration etc. due to delayed program response. Current file selectors block the program for a long time if a directory contains large numbers of files. 
 
I would also suggest UNC path in the form of
/cygdrive/C/My\ Data/... for Windows.

I have proposed Unix like Tab completion of file the path. 
If you agree please vote:
https://bugzilla.mozilla.org/show_bug.cgi?id=478854
#103 "There are currently no reliable ways to keep a
text entry field always visible other than a separate dialog window, like the
file selector."

Are you telling me the browser cannot be coded to display any hidden objects when they are <input type=file ??  Semms like this would be a better way of addressing this issue
PLEASE read all previous discussion before commenting.  These issues have been discussed over and over, especially in bug 258875, which created this bug.  Put simply, you can't possibly block every situation where a file upload could be obscured.  I'm as frustrated by this behavior as anyone else, but we need to create a solution rather than circular discussion.

Don't add a comment unless you've read the background and actually have something new to contribute.
(In reply to comment #105)
> #103 "There are currently no reliable ways to keep a
> text entry field always visible other than a separate dialog window, like the
> file selector."
> 
> Are you telling me the browser cannot be coded to display any hidden objects
> when they are <input type=file ??  Semms like this would be a better way of
> addressing this issue

There are many ways to hide stuff, not just by setting its visibility to hidden or display to none.

But I wonder if anyone has proposed the file control to become unscriptable, or are the implications of that too bad?..
(In reply to comment #86)
> Clearing the file input is a separate bug, for what it's worth.  It's filed,
> and rather unrelated to this one (in that it can be fixed without allowing
> direct filename input).

So WHERE is it filed? Let me know, I want to vote for it, but I cannot find that bug!

From my point of view the inability of type/edit directly the file upload field is very, very annoying, and is real usability flaw; it makes many things harder to do, but still I can do it. So it is P3-P4 bug.
But inability of clearing that field is P0, critical, showstopper bug! I simply cannot imagine how it could be shipped in such shape. Say I have a big, long form, i spent long time on filling it, and there is a input file field. Before submitting, I decided that I don't want to upload the previously selected file. Do i really have to refresh that page, and lost all my work? It's absurdity.
> So WHERE is it filed?

Bug 431098.  Of course had you actually read this bug instead of shouting "WHERE?", you would have known that.  It's quite clearly mentioned in comment 49 and comment 54.  Please do read bugs in the future before commenting on them.  Of course if you think the bug is too long to read, then adding more comments is PRECISELY the wrong thing to do.

> but I cannot find that bug!

That's because you're not looking very well.  Presumably you're using a search that only looks at bugs that aren't fixed yet, and that bug is fixed.
Well, you're right, that's my fault. I've scanned over the whole discussion, but I must have missed the comments #49 and #54. I've also done the text search over the whole thread, searching for keywords "clearing", "clear", "field", "reset" etc, but I didn't searched for "deleting"; actually search for "clear" pointed me to the comment #86 with no reference to the actual bug report.
Also bug search for similar keywords returned no result - perhaps that's really because it is fixed already (that's very strange behavior of Bugzilla to show only open issues in search results, and because Bugzilla is not that popular in this day and age, I've got used to more reasonable behavior of Jira to not exclude fixed bugs by default).
Select "Start private browsing" in a web browser "tools" menu (e.g. in FF) and after that you can add file.
Julia Zakharova" private browsing is version 3.5 or later. And this workaround you suggested does not prevent the file dialog from opening not allow direct input of filename into file upload controls .
Attached file jkhjglkjl (obsolete) (deleted) — 
78itt7o
The content of attachment 692855 [details] has been deleted for the following reason:

Some 'installer.php' file that has nothing to do with this bug.
There is no plan add this feature for the moment. Our current plan is to fully rely on the native filepicker implementations (ie. the MacOS X/gtk2/Windows/etc. filepicker). If those file pickers doesn't allow you to directly type a path, you should file a bug on them.

Feel free to reopen this bug if there is any new information.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
Blocks: 478854
PLEASE REOPEN THIS BUG!

(In reply to Mounir Lamouri (:mounir) from comment #119)
> There is no plan add this feature for the moment. Our current plan is to fully
> rely on the native filepicker implementations (ie. the MacOS X/gtk2/Windows/etc.
> filepicker). If those file pickers doesn't allow you to directly type a path, you
> should file a bug on them.
> 
> Feel free to reopen this bug if there is any new information.

Mounir Lamouri:

You are incorrect:
You claim that the "current plan is to fully rely on the native filepicker implementations"; however, many native implementations DO ALLOW direct input of the filepath.  For example, the native control provided by Windows Forms gives this functionality, although the implementation on Mac OS X doesn't.

Furthermore, direct input used to exist in earlier version of Firefox before it was removed in bug 258875 "Disable direct input of filename into file upload controls".  Therefore, a fix for this bug would restore a feature that was removed, or at least provide the option for the previous behavior.

Next time, please do a little more research before you close a bug as RESOLVED/WONTFIX.

Also, you suggest that if necessary we should open separate bugs for particular filepicker implementations; however, realistically, if anyone opened another bug on this issue, then it would more than likely be closed as a duplicate of this bug!

As of the latest build, Mozilla seems to currently rely on a slightly modified system filepicker control, so why not even provide an about:config setting to reenable the old behavior?

As for any security implications, please ready comment #48:

> And the average advanced user that does go out of their way to turn this feature
> off is going to be more than aware of the hackers trying to steal their files.

This is CLEARLY a highly demanded feature, and it is absolutely ridiculous that users have to resort to add-ons as a workaround.  Also, it is extremely frustrating how bugs such as this one tend to lead to circular discussion and no solution.
The Mozilla dev team should really intervene and come up with a decent solution.
Also the user is seeming lured into wanting to type something in, when VOOSH it becomes a file picker... breaking the bonds of trust. What you need is a filepicker emblem on the side that the user can choose if he wants to be swept away...
(In reply to Alex from comment #120)
> of the filepath.  For example, the native control provided by Windows Forms
> gives this functionality, although the implementation on Mac OS X doesn't.

On Mac, you can use Cmd+Shift+G.

> This is CLEARLY a highly demanded feature

No, that's not clear at all. We have on the order of hundreds of millions of users - ~100 people commenting on a bug does not constitute "high demand".
Overall, peoples, I've fairly gotten used to the behavior, plus using the native file picker for selecting files provides additional features from the underlying OS which FF does not have to replicate.
Let me add a constructive argument to this discussion.

Native OS file pickers suck.
Pasting a path into a textbox doesn't.

Now I don't see a single reason why FF could not allow *BOTH* pasting a text into the textbox and clicking on the button, invoking OS file picker.

Can someone pls explain that?
Ability to drag and drop a file from explorer window to a file upload textbox was a huge time saver when uploading files. Earlier, when textbox was there it would enter the full path of the dropped to the file, no need to open separate file picker. Please re-enable the file upload textbox.
It seems that dragging and dropping a file to the Browse… button actually works. However in my opinion it would be somewhat more intuitive to drag and drop the file to a textbox. I just happened to think of the possibility, it's not that clear at all.
I believe dnd on the widget should work, whether the label or the button. If dropping on the label doesn't work, feel free to file a bug.
What I don't understand is: if drag&grop is allowed, why copy&paste is not?. All you have to check for is that the pasted value matches a readable file, something trivial. 
It would increase usability. In fact, the current version in unusable if you have to process hundreds of paths/files, something, a copy-paste enabled control -as other browsers do- would make-it feasible.
texek, drag&drop is relatively safe because the source has to be a native file browser. Copy&paste, in contrast, can be manipulated by sneaky web pages without you seeing either a filename or a file upload control (as in bug 57770).

If you're on Mac, you can enter a filename by pressing ⌘⇧G in the file picker.
The suggestion in bug 399917 (opening the file picker, defaulting to the pasted filename) might be safe enough.
I have a workaround. As I cannot enter paths but instead must click them in,
I shall instead move the files to /tmp, which is only one directory deep,
and then upload them from there.
I came across this bug and it didn't answer my question, but then I found this blog post which does answer it:

http://winaero.com/blog/how-to-enter-file-location-manually-in-gtk-3-opensave-dialog/

The gist is that the new Firefox GTK 3 file picker doesn't make it obvious how to select a file by pasting the path to that file. But you can type Ctrl-L and then it gives you a text box into which file paths can be pasted. In fact if you just type Ctrl-V then it activates this text box and copies the clipboard into it. However, middle-click doesn't insert the selection as you might expect - use Ctrl-L then middle-click for pasting the X selection.

I don't know if this helps the OP with the "multiple files" problem, but it sure makes my life a lot easier. I know a lot of work went into the file picker UI, with the scroll bars and the box with the files and directories that get highlighted in blue and you can drag and drop them and so on. But for me the fastest way is always to paste a path.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: