Impossible to clear file upload controls (fields)

REOPENED
Unassigned

Status

()

defect
P2
normal
REOPENED
11 years ago
2 days ago

People

(Reporter: rasher, Unassigned)

Tracking

({uiwanted})

Trunk
Points:
---
Dependency tree / graph
Bug Flags:
wanted1.9.1 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments, 5 obsolete attachments)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5

After 258875 got fixed, the new UI makes it impossible to clear a file upload field. Say I pick a file and change my mind later, that I don't want to upload a file along with the form. In FF2 days, I'd simply select the file path in the text box, and delete it. This is no longer possible since that simply brings up the file browser (after clicking on a text field, huh?).

Reproducible: Always

Steps to Reproduce:
1. Fill out form, pick file to upload
2. Change your mind, try to clear the file upload field
3. Utterly fail to do so
Actual Results:  
I'd be able to clear the file field and submit the form without any files.

Expected Results:  
I'm forced to upload the file (or another file, I suppose).

Safari is guilty of the same, but I don't think that's any excuse.
Duplicate of this bug: 422862
ccing roc and some folks who might know something about UI design.  Not sure who else would be good to cc in that vein, so deferring to the Mikes on that.

Confirming, since it really would be nice to have good UI allowing this.
Blocks: 258875
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: uiwanted
OS: Windows XP → All
Hardware: PC → All
Version: unspecified → Trunk
I'd suggest a context menu item (hasn't that been proposed before?)
Not very discoverable, but maybe the best option available.

Comment 5

11 years ago
Would it be possible to add a little X button to the inside of the field--similar to what is done for the library's search box--when the field contains a filename?

Comment 7

11 years ago
This is a extension for Firefox3.0. This add right click/Shift+F10 menu to clear file upload fields(input type=file) .

Clear File Upload Fields( https://addons.mozilla.org/en-US/firefox/addon/7296 )(In Sandbox)
Add right click/Shift+F10 menu to clear file upload fields(input type=file) 

Comment 8

11 years ago
Clicking on the textbox brings up the file browser, so you can't type in or copy paste a file path. That seems like an unnecessary limitation?
Ideally there shouldn't be a textbox there at all. But rather a browse button and then normal text showing the path for the selected file. That way you can copy the path if desired (though I think it's something very few people actually need)

Comment 10

11 years ago
Could you guys revert the file upload controls to the way they were in ff2? I was used to 'copy' a file from nautilus and then 'paste' it in a upload field. It worked just fine. Hell, sometimes when I'm uploading a lot of stuff, I want to just change a number or two (with large sets of images for example), not open some dialog that doesn't remember which file I uploaded last. That's what the browse button is for.

Now it's impossible to fill or clear the field normally. It's the exact opposite from 'usable'.

Comment 11

11 years ago
If you click on the "Browse" button, it's still possible to type and copy-paste into the dialog box, but yes, that does add an extra step.

Comment 12

11 years ago
I am also having this issue - since Firefox remembers form data, this makes it impossible to remove text entry from a page without an easily accessible backlink, like those on a certain very fast-moving subforum of 4chan. If you click back to the main index to try finding the thread link again, you'll probably be there for whole minutes trying to find a link. However, if you refresh, the last thing you submitted stays in the box.

This is extremely annoying (and in some cases, insecure)! I see no reason why that text input box needed to be disabled - people could also paste filenames directly into it and that made life somewhat easier for mass upload inputs. It certainly wasn't a problem. It is a problem now that people are unable to remove a value from the input!

I'd like to see file input-box functionality reverted back to the old FF2 style, because everything else in FF3 is seriously great work (thank you for image download placeholders in the latest RC, finally!).
Flags: wanted1.9.1+
Priority: -- → P2

Comment 13

11 years ago
Posted patch Makes textbox write-able (obsolete) — Splinter Review
Reverting to FF2 seems pretty straightforward, but I'm not sure it's the right thing to do. Perhaps adding a clear button (comment 5) would be better?

Comment 14

11 years ago
Honestly, in my opinion, after having read the bug report that causing this problem "fixed", I think that having the text field editable is no more exploitable than someone downloading a virus from a site claiming to be "free antivirus". It's all PEBKAC. If it relies on the user to be misled into typing a filename into a browse box, then that relies on a lot of iffy factors that Firefox should have nothing to do with - that the file actually exists in that location (and is readable, unlike say, the system/user registry in Windows), and that the user's actually ignorant enough to type or paste the filename into the box.

It's cutting off a lot of usability in the name of marginal "security", much like the "save file" restriction on EXEs is as well (I use OpenDownload to bypass that - but why should I need an extension to restore lost functionality?).

Unfortunately I'm not a coder (I don't even have a compiler or the FF source), so all I can do is comment on the usability from a user's standpoint.
> If it relies on the user to be misled into typing a filename into a browse box

Uh... did you really read that bug report?  The point is that it's possible to do this without the user ever seeing the file upload control or realizing they're typing into it.

> that the file actually exists in that location (and is readable

You mean like the user's Quicken files, say?  Or /etc/passwd on Unix systems?  Or a whole bunch of other files users can typically read?

> and that the user's actually ignorant enough to type or paste the filename
> into the box.

The fact that you can say that with a straight face indicates to me that you did not in fact read bug 258875 (which includes reading the various other bugs and testcases it references, like bug 56236, bug 57770).

Again, everyone agrees that _this_ bug should be fixed.  That's not at issue here.
(Reporter)

Comment 16

11 years ago
How about this?

FF2 behavior is reverted.
To fix bug 258875, if the user submits the form with a file selected, without having clicked the browse-button, a confirmation dialog is shown.

For regular use, behavior should be exactly like FF2. Only when the user does something unusual (by typing in the field manually, on purpose or by being tricked), will the confirmation dialog be shown.

Comment 17

11 years ago
> Only when the user does
> something unusual (by typing in the field manually, on purpose or by being
> tricked), will the confirmation dialog be shown.

Now that's usability. I can live with that. I hadn't even thought of the usability problems in HTTP uploads anyway (being a developer of a file hosting site, it's been a nightmare). A dialog confirming that you are uploading a file.

> Uh... did you really read that bug report?  The point is that it's possible to
> do this without the user ever seeing the file upload control or realizing
> they're typing into it.
Are there honestly people out there that would blindly type a path into their browser without even being able to see where they're typing? Yes, I read it, but I dismissed the possibility of someone actually being dumb (or talented?) enough to blindly type into a control of any kind without being able to see the result... unless of course another control is mirroring its contents to appear like a text box or something, but still - a whole lot of effort for very little gain! Why have I never even seen such an exploit? I just think the file input box should have been left alone like it has for so many years. We should be concerning ourselves with integrating a file-upload-progress indicator of some kind (that would actually be universally useful) and less time concerning ourselves with fixing exploits by removing functionality... IMO.

But I think the confirmation dialog is a perfect balance of usability and security. It also helps give the first step towards actually providing user feedback to file uploads, something that's been sorely lacking ever since the first web browser to support it. Quite frankly, I'm shocked that there has been so little user interaction regarding the way file uploads are handled. Not even as much as a "this file is being uploaded" message has been integrated into any browser (except Opera, to an extent). The least Firefox can do is provide a safety dialog box like it does everything else. ;)
The typical user response to a dialog is to randomly select a button and click it (this is the case for well over 90% of users).  So your suggestion is that half the time users be exploitable.  That's not acceptable.

In any case, it's easy for the site to have the user select a file and then change the path...

Seriously, people thought about the problem for a number of _years_ before the change in bug 258875 was made.  That change is really the only way to reliably fix the security issues here.

Again, none of that directly impacts this bug.
> Are there honestly people out there that would blindly type a path into their
> browser without even being able to see where they're typing? 

Look.  Go read those bugs.  _Carefully_.  Read especially carefully the parts where the file path is assembled one character at a time from text the user is typing elsewhere, or from key events in general (e.g. from the user using keys to play a game).

> unless of course another control is mirroring its contents to appear
> like a text box or something

Yes, this is _exactly_ what happens in some of the bugs and testcases you claim to have read.  Except it doesn't mirror: it shows a superset of the contents.

> But I think the confirmation dialog is a perfect balance of usability and
> security. 

A confirmation dialog is usually a perfect balance of lack of usability and lack of security.  Please go read some of the literature on user-interaction studies involving confirmation dialogs.
(Reporter)

Comment 20

11 years ago
> The typical user response to a dialog is to randomly select a button and click
> it (this is the case for well over 90% of users).  So your suggestion is that
> half the time users be exploitable.  That's not acceptable.

So make the dialog have 5 buttons, only one of which uploads the file. Presto, less vulnerability!

Is it really necessary to sacrifice actual usability in the name of a theoretical vulnerability that might hit people who refuse to read and respond to a simple question?

> In any case, it's easy for the site to have the user select a file and then
> change the path...

So change the logic to "if the path has changed since the user pressed the browse button, or page-load, whichever happened last".

And I really do think it's relevant to discuss this, if a kludge could be avoided to fix the problems created by the "fix" to bug 258875.
Can you please have this conversation somewhere else. It has nothing to do with this bug.

I would prefer a newsgroup since that won't spam people the same way comments in bugs do. mozilla.dev.tech.html for example.

Comment 22

11 years ago
In addition to the newsgroup, there's a thread at mZ <http://forums.mozillazine.org/viewtopic.php?t=637083> and bug 374011, both of which would be more appropriate (as this bug is specifically about clearing the upload field)

Comment 23

11 years ago
(In reply to comment #22) (and sorry for the off-topic-ness)
Unfortunately MZ isn't really an option for me... I got banned a few years ago for trying to argue the fact that Firefox has gotten to be an out of control memory hog. Seems that a year after I brought it up, the public took notice, and a year after that, they finally did something about it. But that doesn't help the fact that I've been banned... *yay* for mature leadership. Banning is for spambots, not people with strong worded statements... *sigh*

Anyway, all the conversation in this bug thread so far has been about the functionality of the upload field, including the original report, so it's not really unrelated. I find this format convenient since it brings more people into the conversation. I do, of course, prefer an online forum (like mZ), but not one that will ban a person for having a statement about a matter such as myself. Mailing lists just stink, and newsgroups should have died in 1990 (and as far as it's concerned me, they have). Are there any alternatives?

Personally, I'm of the mind that Firefox should not be the "internet babysitter", preventing people from visiting "possibly bad" sites and whatnot. I saw that thread and I experienced that exploit (the c:\autoexec.bat paste trick) with IE. At the very least, that "unfunctionality" (the intentional disabling of features, like "open" on EXEs and the text field on file boxes) should be able to be disabled for those of us that actually know what we're doing online. The point still stands that anyone that misses the "Browse" box and mistakes it for a password field shouldn't be anywheres near a computer, effectively nullifying that exploit.

As I mentioned before, I believe this is wholly relevant to the bug at hand, as the bug is created by a "fix" for a supposed "security issue". The solution is to either nullify the original security issue or find another way to resolve it that also resolves this new issue. The solution is not to take it elsewhere; as then the people who may be making the changes won't have this discussion to read through and consider.

With that, this will be my last post in this thread for a while, so worry not. My statement of the facts I understand are on the table to do what you like with. As both a web developer and a user I find this bug fix quite annoying, so let's see what can be done about it?
QA Contact: layout.form-controls → nobody
QA Contact: nobody → layout.form-controls

Comment 24

11 years ago
I thought about this thing for a while now.
There are a few ways to fill a file upload 'textbox' -- pre-filled from html, copy&paste, typing, the browse button and javascript. Only two of those are a potential security threat. Let's just show a warning dialog (OK/CANCEL) when the upload box is pre-filled or tampered with by a script. Limiting the user in other cases isn't necessary.

Updated

11 years ago
Duplicate of this bug: 440086

Comment 26

11 years ago
Do you call this an ehnacement to security? I experienced data leak today because of this very bug! And workaround for some reason requires mail-confirmed registration to get installed. I'm killed, just killed.

Comment 27

11 years ago
(In reply to comment #26)
>And workaround for some reason requires
> mail-confirmed registration to get installed. I'm killed, just killed.
> 

That's because AMO won't show experimental extensions to anonymous users, a security measure ironically enough.
Duplicate of this bug: 443439

Comment 29

11 years ago
Posted patch WIP, a clear button (obsolete) — Splinter Review
Attachment #324854 - Attachment is obsolete: true

Comment 30

11 years ago
Posted patch Fixed tab focus, passes tests (obsolete) — Splinter Review
Attachment #328007 - Attachment is obsolete: true
Is there any way to avoid adding yet more complexity to the frame constructor for this?  That file needs to become smaller and simpler, not ever more baroque.
I'm not sure why that frame constructor code is needed.

I'm not sure why we need to set the src of the close button. In fact I don't know why we need a type="image" input at all for this button, can't we use a regular <button>?

Comment 33

11 years ago
Attachment #328210 - Attachment is obsolete: true
Before we go ahead and add another button to every file control on every button we should make sure that the UA people etc are in agreement on that being the right approach here. Beltzner, what's your thoughts on this issue?
Additionally, if we change the size of the control, it is going to be hard to make sure that we don't break the layout of various web pages out there that use the control.

I think a context menu option would be the best way to go. It would be trivial to add code to our normal context menu to do this as all you need to do is to set input.value = "" from chrome.

Updated

11 years ago
Duplicate of this bug: 448799
Context menus aren't that discoverable either.

Comment 38

11 years ago
Could there be a possibility to add a config option for allowing editing of the file upload fields? Or is it against some Mozilla policy? Because artificially punishing good (clever :) people (developers, etc, who upload lots of files) is not fair. They WILL start to use another browser (or patch Firefox) to just upload the files.
it is not a matter of being smart or not. It was *impossible* to see that you were typing into a file controll because it was invisible! There are countless ways of completely hiding the controll. Any time you were typing ok a page you were running the risk that some key strokes were stolen and used to build a file name. We tried to make the stealing impossible, but it was just a never ending game of whack-a-mole which just was not reliable enough to guarentee that we had fixed all possible ways.

Put it this way, before you wrote that last comment, did you use view-source to make sure Bugzilla didn't have a hidden file controll that was stealing your let strokes? Cause if you didn't there might have been an unknown bug that allowed Bugzilla to steal files from you.

Comment 40

11 years ago
A "clear" button won't affect layout as long as the button is inside the filename box, like the bookmark star in the address bar.  That's probably the cleanest way to display it: an X icon right-aligned inside the field.

Also, it should be possible to clear the filename when the selector dialog is open by hitting "OK" ("open") with the pathname field cleared.  This would probably need platform-specific changes to allow each platform's file selection dialog to be OK'd with no file selected.
Summary: Impossible to clear file upload fields → Impossible to clear file upload controls (fields)

Updated

11 years ago
Duplicate of this bug: 464177
Duplicate of this bug: 466277

Comment 43

11 years ago
(Sorry in advance for bugspam, but I hope to be useful)
If the decision has been made not to allow pasting or manual input of the filename, then I, just like a few others, want to suggest to redesign this input completely.

For example, why not make it look like a Gtk File Chooser Button (http://library.gnome.org/devel/gtk/unstable/GtkFileChooserButton.html), but with an additional subwidget that would clear the selected filename? It could then be a button looking like this:

[T Filename     |X]

where T is the file type icon, and X is a "Clear" icon.
or

[T Filename   |O|X]

where T is the file type icon, O is the "Open file" icon, and X is a "Clear" icon.

OTOH, (esp. if there are plans to actually introduce the functionality requested by Bug 373866 and Bug 63687), the solution proposed in Comment 40 would be an easy temporary workaround for this problem.
Duplicate of this bug: 477411
Duplicate of this bug: 481666

Comment 46

10 years ago
Looks like I entered a dupe.  One solution of which some variation appears to have been suggested here as well, but a specific implementation might be useful in making a decision.

Google Chrome has a similar file dialog, but if the user presses Cancel within the dialog, then the previous choice is removed.
Posted patch Clear on cancel (obsolete) — Splinter Review
That is such a brilliantly simple idea that I wrote up a patch :)
Attachment #366046 - Attachment description: Patch to fix → Clear on cancel
Attachment #366046 - Attachment is patch: true
Attachment #366046 - Attachment mime type: application/octet-stream → text/plain
Posted patch Clear on cancel -w (obsolete) — Splinter Review
Attachment #366047 - Flags: ui-review?(beltzner)
Attachment #366047 - Flags: superreview?(bzbarsky)
Attachment #366047 - Flags: review?(bzbarsky)
Attachment #366047 - Attachment is patch: true
Attachment #366047 - Attachment mime type: application/octet-stream → text/plain
Comment on attachment 366046 [details] [diff] [review]
Clear on cancel

Wrong patch
Attachment #366046 - Attachment is obsolete: true
Attachment #366047 - Attachment is obsolete: true
Attachment #366047 - Flags: ui-review?(beltzner)
Attachment #366047 - Flags: superreview?(bzbarsky)
Attachment #366047 - Flags: review?(bzbarsky)
Attachment #366049 - Flags: ui-review?(beltzner)
Attachment #366049 - Flags: superreview?(bzbarsky)
Attachment #366049 - Flags: review?(bzbarsky)
Attachment #366049 - Flags: superreview?(bzbarsky)
Attachment #366049 - Flags: superreview+
Attachment #366049 - Flags: review?(bzbarsky)
Attachment #366049 - Flags: review+
Comment on attachment 366049 [details] [diff] [review]
Clear on cancel -w

Looks good, though I'd prefer if we didn't even ask the picker for a file if mode == cancel.  Can you add that check around the GetFile call?
Comment on attachment 366049 [details] [diff] [review]
Clear on cancel -w

Very simple patch, and nice improvement for users.
Attachment #366049 - Flags: approval1.9.1?
Seems odd to have an approval1.9.1 request on something that isn't yet fixed in mozilla-central.

I'd also note I'm not really a big fan of this approach:  I think "Cancel" buttons should do exactly that:  cancel, rather than taking some action.  (I'd much rather see clear as a context menu item + button ... although that's part of the larger file upload redesign that we need to do.)
Sorry, forgot to mark fixed. This was checked in on march 9th.
http://hg.mozilla.org/mozilla-central/rev/2e5e44527a3f

I would definitely be open to other UIs, but I thought that this was better than what we had, or was likely to get in the immediate future.

If you think of the second time the user brings up the filepicker as part of the same action, it does make sense that cancel clears the field. I.e. it cancels the whole action of attaching a file, not just cancels the current file picker dialog. This could further be enforced by the second time selecting the currently picked file.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
> This could further be enforced by the second time selecting the
> currently picked file.

We do that already (modulo bugs).
I'd like to see ui-review+ on this before taking it on 1.9.1 (or central, really).

Comment 58

10 years ago
But if you accidentally hit the picker again (another good example of why I think it's a very bad idea to make clicking the text field be the same as clicking the button) or think you might want to change your file and change your mind, you'll have to pick your file again.  Not very intuitive.  

I still think a separate clear button would be much simpler and intuitive than clearing it with the Cancel button.  Good UI design means that Cancel only removes the current action (choosing a file), not taking action.

Comment 59

10 years ago
Yes, Cancel needs to return you to the previous state.  Under this proposal Cancel effectively becomes not Cancel but "Reset" or "Clear".

I appreciate the rationalization made in Comment #55, but don't agree that bringing up the file picker a second time can be treated as part of the same action.  To do so would be to break this scenario:  "Oops, I opened that window again by mistake.  I've already selected that file.  Cancel."

Cancel is the quickest possible way back if you find yourself opening a window by mistake.  Users trust it not to change anything they've done already.
Comment on attachment 366049 [details] [diff] [review]
Clear on cancel -w

This really feels like the wrong UI, and makes Cancel not a no-op.  I definitely don't want this on 1.9.1, since it's super late and not something I think we want to shove down users' throats. (lookit me being a big ol' softie again)
Would probably be good to get it backed out of mozilla-central as well, then.

Comment 62

10 years ago
Looks like I can keep this image around a little longer, then...

Comment 63

10 years ago
(In reply to comment #62)
> Looks like I can keep this image around a little longer, then...

Forgot my pic, heh:
http://img258.imageshack.us/my.php?image=filefield.jpg

(Yes, I actually do use it on occasion.)
Attachment #366049 - Flags: ui-review?(beltzner)
Attachment #366049 - Flags: ui-review-
Attachment #366049 - Flags: approval1.9.1?
Attachment #366049 - Flags: approval1.9.1-
Comment on attachment 366049 [details] [diff] [review]
Clear on cancel -w

Not approving as per mconnor's recommendation, with which I agree.

Comment 65

10 years ago
Other possible options?

1) Add a button to the control itself, within the "text field" to the right of the text.  The button could be a red X, with "clear file selection" tooltip, or something similar, and it could be only visible when a file is selected.  Variations on this appear in Comment #43.

2) Add an option to the right-click context menu called "clear file selection" or similar.  Probably easier to implement, but less discoverable.

3) Add new button to the file open dialog alongside the OK and Cancel buttons which says something like "clear file selection".  This may be too complicated due to cross-platform issues and changing that dialog could have too much of an impact on consistency.

4) Make the text field editable.  Problems with this solution have already been discussed, ie it can have security implications depending on implementation.

Comment 66

10 years ago
There is yet another option, which was already mentioned in bug 374011:
5) When the user clicks on the content area of the file input control, display an "proxy" dialog window that contains an editable file input control with focus in the text field, a Browse button and probably OK and Cancel buttons. This makes the file input control editable and clearable without being a security problem and introducing new UI elements like special clear buttons, context menus or whatever. If the user clicks on the browse button (either directly or inside the dialog window), the OS filechooser is displayed. Dismissing/affirming the filechooser also hides the dialog box.

The old behaviour:
User clicks the file input control which places the focus inside an editable text field

Current behaviour:
User clicks the file input control which opens the filechooser

New behaviour:
User clicks the file input control which [displays a proxy window and] places the focus inside an editable text field (this could probably be implemented in such a way that if the user selects part of the text in the original filechooser, the text is automatically selected in the proxy dialog window as well).

Comment 67

10 years ago
This bug shouldn't be marked as fixed. It's wrong, and confusing. 

And, please remove that 'fix' from trunk. not only this is not a fix, it's a newly introduced bug.
I filed bug 503416 (blocking1.9.2+) on backing this out.
Voted for bug 503416.

This bug shouldn't be marked as fixed since no actions were taken (besides that, the cancel button is a terrible idea, IMHO).

Comment #65 shows some good ideas; personally, I think the best solution is a combination of suggestions 1 and 2: add a clear button inside the text field AND add a context menu, which is not very discoverable, but its use would be secondary.

Comment 71

10 years ago
(In reply to comment #66)
I had actually mentioned a similar solution in bug 258875 more than 3 years ago.  https://bugzilla.mozilla.org/show_bug.cgi?id=258875#c69  
I never did receive a response.
Duplicate of this bug: 510784

Comment 73

10 years ago
I recommend:

1: Add the context menu option, as several have suggested.  Regardless of whether it's discoverable enough on its own, it definitely should be there.  That would solve the fundamental bug, rather than having it continue to linger looking for the complete solution.

2: If that's not discoverable enough, then adding a "clear" button is not good UI.  This operation is important, but it's rare.  Taking up layout/screen space, tab-order space and visual clutter for a rare operation is not a good approach.

Instead, I'd recommend adding a small embedded button into file input fields, like the location bar's dropdown and favorite buttons.  Clicking it would simply open the context menu, consisting of at least "Browse" and "Clear".  This would replace the Browse button and eliminate the need to add yet another button for Clear.  This is redundant UI with right clicking to open the context menu, but it offers the visual cue needed to make it discoverable.  It would also replace the Browse button's job of enabling keyboard navigation.

This has the nice bonus of making file input fields not ugly again; that browse button is cosmetically hideous, at least in Windows.

Updated

9 years ago
Duplicate of this bug: 540965
Duplicate of this bug: 548264

Comment 76

9 years ago
I second comment #73. It's been an entire YEAR since this bug was logged on some seriously broken functionality in Firefox. There has been several proposed patches even. Just do SOMETHING to fix this bug!

Comment 78

9 years ago
I would very much appreciate it if Firefox would take an approach akin to Konqueror's (see attachment). It has a small inline <X] button that shows up when the field is filled, and a "Clear" option in the context menu.

Anyone still struggling with this issue should have a look at the following extension, which adds the second of the two features.
https://addons.mozilla.org/firefox/addon/7296/
(In reply to comment #78)
> I would very much appreciate it if Firefox would take an approach akin to
> Konqueror's (see attachment). It has a small inline <X] button that shows up
> when the field is filled, and a "Clear" option in the context menu.

I second that. 

This bug may not affect me much, but when it does, it hits hard. Please fix it for Firefox 4.

Updated

9 years ago
Duplicate of this bug: 604672

Comment 81

9 years ago
Chrome supports clearing the file upload if you click "Cancel" in the file chooser. That's not a bad way to do it.

Comment 82

9 years ago
(In reply to comment #81)
> Chrome supports clearing the file upload if you click "Cancel" in the file
> chooser. That's not a bad way to do it.

That behavior is wrong.  Cancelling a dialog in Windows closes the dialog and puts you back where you were before you opened it, without taking any action.  Clearing the selection is taking an action.

This behavior is broadly standardized in Windows for a reason: so you know that if you open a dialog accidentally, you can always click Cancel (or press escape) to undo opening it without changing anything.  You don't have to analyze which dialog you opened to find the correct way of closing it.  Chrome may broadly ignore system UI conventions, but Firefox should not.

Comment 83

9 years ago
(In reply to comment #82)
> That behavior is wrong.

You know what other behavior is wrong? A file upload control that can't be cleared. Sometimes two wrongs make a right.

But if it will appease the pedants, how about a menu option? Tools -> Clear file upload fields on current tab

Wow I should be a software engineer. And this bug has been open for 2.5 years? Come on now...

Comment 84

9 years ago
Two wrongs make two wrongs.  This isn't pedantic, this is user interface 101: be consistent.  If I open a dialog by accident, I press escape without looking very hard at what it was.  If a program responds to my pressing escape by *clearing the previous selection*, it has responded incorrectly and done something unwanted.

The solution I proposed earlier is: remove the browse button, and replace it with an embedded dropdown button (like the one on the right-hand side of the address bar, except focusable) which opens the context menu; add "browse" and "clear" to the top of that context menu.  This fixes both the file-clearing problem, and the big, ugly "browse" button which is bolted awkwardly to every file field, and it remains keyboard-accessible.
Duplicate of this bug: 675505
BESIDES fixing this bug and enabling the user to CLEAR the file field, there MUST also be the possibility to MANUALLY edit the file path as text. It is necessary in a number of situations. Copying and pasting a path is just one of them. And you may want to paste the path but manually change a "1" for a "2" and the like.

The security risks are a good point, but impeding to edit the file path completely is not an acceptable solution. The one proposed by Jonas Häggqvist is a good one in my opinion, there may be better ones, but DEFINITELY, manually editing the file path MUST be possible.

As a side effect, this would indeed allow you to just select the path and delete it with the DEL or BACKSPACE keys, which would actually fix _this_ bug as a side effect, and it would be much better than a context menu or a clear button/icon.

Comment 87

7 years ago
Very stupid and annoying behavior! Every action on a form MUST be reversible, if you chose a file and then you change your mind, you should be able to clear the file upload.

Clear the file name in the browse file dialog and chose "open" should clear the file input
Or after canceling the file dialog hitting delete, backspace or esc should clear the file input.

Comment 88

7 years ago
I’d agree with the others. All of the form actions should be reversible. It is nonsense that one has to load the page again and cut & paste everything he or she filled in the form in the first place.

At least, there should be a little × on the right side of the text box (which is pretty common nowadays, so everyone understands what it does).

Also, it would be really cool to have a possibility to edit the content of the text box manually (which can be very useful when you have to change something in the path and you already know what exactly you want to change). Maybe after enabling it in the settings, or in about:config, but definitely there should be a way to get this to work.

Comment 89

6 years ago
One thing we may use is:
If the user cancels when the file picker appears, then clear the input control.

We already have it as:
When the file picker appears, select the previously selected file.

So it should be quite easy to do, and better, considering that we don't have any UI at all yet for this.

Comment 90

6 years ago
(In reply to brunoaiss from comment #89)
> One thing we may use is:
> If the user cancels when the file picker appears, then clear the input
> control.
> 
> We already have it as:
> When the file picker appears, select the previously selected file.

IMHO, This is a bad idea because:
1. Cancel should always mean tao not modify anything, not "change it to nothing"
2. If one has navigated to somewhere else and decided to change their mind, then that is when wants Cancel to not modify anything the most.

Comment 91

6 years ago
Good point...

The "x" idea sounds good actually. Why no one did it?

Comment 92

6 years ago
We should consider mouse as well as keyboard to clear them.

Comment 93

6 years ago
true. My ideas:

Option 1:
While tabbing,
Tab until selecting the input. Then tab again and the "X" becomes selected Clicking the "Enter" will trigger the click on that "X" as if it was the mouse. We can allow the js to detect this "X" but we should not(?) allow the js to block it's action from occurring.

Option 2:
While tabbing,
Tab until selecting the input. Then use a keyboard shortcut, for example, the Delete button, to clear the contents of the input@file.
Comment #65, comment #69, comment #77, comment #78 and comment #91 all point the same ideas to solve this bug;

comment #78 also shows an extension that already implemented one of the proposed solutions

Comment 95

6 years ago
In that case, why none was applied?
Is everyone, who's capable of doing it, too lazy to make the GUI?

Comment 96

6 months ago
Seems that an easy work-around is to clear the file upload element by JavaScript.
Upon click on something (icon of a garbage can), do a 

	   upLoadElement.value=null;

It still would be great that also users who do not allow for JavaScript could clear easily by the browser proper.
You need to log in before you can comment on or make changes to this bug.