If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

File input fields disabled by default and can't be edited

RESOLVED DUPLICATE of bug 374011

Status

()

Firefox
Keyboard Navigation
RESOLVED DUPLICATE of bug 374011
9 years ago
4 years ago

People

(Reporter: VZ, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0

After upgrading to Firefox 3 all file input fields are disabled and can't be edited and, worse, can't be TAB-bed to any more. For those of us more used to using keyboard it would be really convenient if this behaviour could be disabled.

Reproducible: Always

Steps to Reproduce:
1. Open any page with an <INPUT type="file"> entry, for example https://bugzilla.mozilla.org/attachment.cgi?bugid=1000&action=enter
2. Verify that you can't get to the (disabled) "File" field using TAB

Updated

9 years ago
Whiteboard: DUPEME

Comment 1

9 years ago
I suspect this is part of Mozilla's locking down of file inputs. They don't want you typing in there. BAD USER!

The whole point of the Free Software movement was to allow users to use the software how they wanted to, but Mozilla's new nanny-state approach declares that users don't have any business editing file inputs by hand, you MUST use the GUI. Nevermind the fact that once you select a file you have absolutely no way to clear the field...

It's for your own good! You can't be trusted with such things!

Add a pref in the options? NO!
Add an about:config variable to disable this behavior? ABSOLUTELY NOT!

It's up to US, the infalliable Mozilla dev team, to protect our knuckle-dragging drooling idiots users from themselves, even if it means screwing everyone else who has a clue! GOD BLESS WINIFRED MITCHELL BAKER!!

Comment 2

9 years ago
> can't be TAB-bed to any more

I'm not sure what's up with that.  I imagine it prevents you from copying the filename out of the field using the keyboard, or seeing a long filename in a small box.  Probably worth filing a separate bug report on, with the "access" keyword.  Or maybe Ctrl+C while the "Browse..." button has focus should copy the path.

Or maybe we could just show the filename and not the complete path, and make it not look like a textbox (imitating Safari).

> For those of us more used to using keyboard it would be really convenient if this behaviour could be
disabled.

I've found that platform file pickers do a pretty good job of letting you select a file with few keystrokes.  You can type just part of a folder name, then press Enter (Windows) or the right arrow key (Mac) to indicate that you are done with that part of the path.  If you really want to, you can type a complete absolute path instead of using the graphical part of the file picker.  Mac even combines the two with Cmd+Shift+G, which lets you type a complete path with Tab completion available.

Skipping the empty textbox lets you save one Tab keystroke to get to the file picker.

Am I missing an advantage of the "type a complete absolute path and filename" approach?

> Nevermind the fact that once you select a file you have absolutely no way to clear the field...

A bug that will be fixed: bug 431098.

> to protect our knuckle-dragging drooling idiots users from themselves

I don't think you've seen the exploits for the security holes related to direct input of filenames.  You don't have to be an idiot (or drooling) to fall victim.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 374011

Comment 3

9 years ago
See bug 345195 for the accessibility-API angle.

Updated

4 years ago
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.