<input type=file> does not accept textual input

Bug #209509 reported by Ing0R on 2008-03-31
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
XULRunner
Fix Released
Medium
firefox (Ubuntu)
Undecided
Unassigned
firefox-3.0 (Ubuntu)
Medium
Unassigned
firefox-3.5 (Ubuntu)
Medium
Unassigned

Bug Description

Binary package hint: firefox

Firefox 3 (3.0~b4+nobinonly-0ubuntu1) immediately opens a "file upload" dialog when I click on the file name field. Ff should only open this dialog if click on [Browse...]. Even after I close the dialog window I can neither input a file name directly into the field nor can I remove the file from the input field.
It should be as easy editable as in firefox 2.

I use Hardy amd64.

Created an attachment (id=229814)
Testcase

This was changed in bug 258875.

So it sounds like we want something focusable but not editable, right?

Perhaps we should simply use an overflow:auto inline block or something?

The Browse button is still focusable, no? So given that we can't allow typing in the textfield, why does it need to be focusable?

(In reply to comment #3)
> So it sounds like we want something focusable but not editable, right?
>
> Perhaps we should simply use an overflow:auto inline block or something?
>

I hope no. Previously I copied path from command line and then pasted it into text field. Now I'm forced to spend five minutes to locate needed file.

(In reply to comment #5)
> (In reply to comment #3)
> > So it sounds like we want something focusable but not editable, right?
> >
> > Perhaps we should simply use an overflow:auto inline block or something?
> >
>
> I hope no. Previously I copied path from command line and then pasted it into
> text field. Now I'm forced to spend five minutes to locate needed file.
>

You can paste the FQ path into the file dialog. I do all the time. On Windows, at least.

I think the reason this bug was opened was because it now is impossible to copy the filename (though I must admit I don't see much use for that, but I agree that it'd be good to allow).

I think we should seriously revise the look of the file-control. The safari one is really nice. Basically it looks like ours, except that it doesn't contain a text-field, rather just the filename as text. If the filename can't fit they use centered ellipsis to shorten it. Additionally they show the appropriate file icon next to the text.

When it comes to focusing I think we should treat the whole thing as one unit. Clicking anywhere in it should open the filepicker (as now) and we can make copying the control copy the filename (don't know how easy that is).

Additionally, we could maybe add an item to the context menu that brings up a dialog box with a simple editable textfield. That way it's still possible to both paste and edit the selected filename. Though I'm not sure how important it is given that only tech-savvy users that prefer to use the keyboard rather than the mouse has a big need to type the filename, and such users will probably not like having to go through a context menu. Oppinions welcome.

(In reply to comment #7)
> I think the reason this bug was opened was because it now is impossible to copy
> the filename (though I must admit I don't see much use for that, but I agree
> that it'd be good to allow).
>
> I think we should seriously revise the look of the file-control. The safari one
> is really nice. Basically it looks like ours, except that it doesn't contain a
> text-field, rather just the filename as text. If the filename can't fit they
> use centered ellipsis to shorten it. Additionally they show the appropriate
> file icon next to the text.
>
> When it comes to focusing I think we should treat the whole thing as one unit.
> Clicking anywhere in it should open the filepicker (as now) and we can make
> copying the control copy the filename (don't know how easy that is).
>
> Additionally, we could maybe add an item to the context menu that brings up a
> dialog box with a simple editable textfield. That way it's still possible to
> both paste and edit the selected filename. Though I'm not sure how important it
> is given that only tech-savvy users that prefer to use the keyboard rather than
> the mouse has a big need to type the filename, and such users will probably not
> like having to go through a context menu. Oppinions welcome.
>

I agree that if we are not going to exhibit readonly textfield behavior, then we shouldn't display a readonly textfield. However, if we want to allow copying from the file input, then I believe that the readonly textfield is a cleaner solution than having to trigger a dialog from a context menu. So I vote that we should fix up file input to behave correctly. I would argue that most users are already familiar with the readonly textfield and what you can and cannot do with it.

But a control like Mac's wouldn't be all that bad as long as we can do it in such a way that the file input text can be easily differentiated from surrounding text and from its label if it has one.

(In reply to comment #7)
> I think we should seriously revise the look of the file-control. The safari
> one is really nice. Basically it looks like ours, except that it doesn't
> contain a text-field, rather just the filename as text.

fwiw that was bug 314365 which got WONTFIXED.

It's not clear to me _why_ it got wontfixed -- no good reasons were given past "that's just the way it is".

I think we should consider moving forward with that more mac-like control...

a further observation is the current behaviour is that only the button is in the tab order but you can focus either with the mouse.

Not only that, but you can keep the text frame focused if you click on it, and then hit Escape in the file chooser.

It's reporting that it is focusable.

The decision was made to not make any more changes in bug 258875. It's not clear to me what else needs to be done here.

On the usability issue issue the Mouse and keyboard UI's are slightly different. This gives users a confusing conceptual model. I see the main issue is that as you can get a caret in the readonly text box it appears you should be able to interact with it in some way but you have really got into a 'dead' state that you must get out of. So should it be focusable or not?

On accessibility side the ro text control is exposed as state:focusable (which agrees with the above behaviour) which could be taken to indicate that an AT can legitimately give it focus - clearly not the intention and again gets a dead state. It also appears as editable text and has an action of 'activate' that does nothing (should pop up the picker?)

So if the usability is going to stay as is then I think the accessibility needs to change to remove IeditableText and make the activate action pop up the picker

To be absolutely clear, if the intention is that the only way of setting the text is through the picker then the a11y API should have the same symantics.

Aaron, can you make the accessibility change here?

Assigning to Aaron for now. This bug will fall off the blocking list if someone doesn't pick it up soon.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2
JRE version 6 update 10; (build 1.6.0_10-ea-b11)

1- When on a Yahoo page that displays characters for verification; one can set the focus of the input text field by using a mouse click or the tab; see:

http://info.paperlessprocess.com/Firefox/TextField_Gets_Focus.jpg

2- But when the same window is resized to the point that the text field moves its position; the mouse click will not get focus; although tab will; see

info.paperlessprocess.com/Firefox/TextField_cannot_Focus_with_mouse-click.jpg

3- This problem cannot be produced in the main sign on page of Yahoo because resizing the window does not change the position of the text field; it crops it.

4- IE does not have this problem.

Created an attachment (id=304786)
file to test setting focus to an input type=file field programmatically

You can also not programmaticaly set focus to an input type=file. Test file inputFileFocus.html attached. Open inputFileFocus.html and tab to the first button (Something to focus before table). With focus on that button, click the "focus first field" button. That should set focus to the input type=file field labeled with "ID file:" - it does not. Focus goes to the document. IE and FF 2.0.0.12 do not have this problem.

I also would seriously consider changing the behavior of the input field.

Sorry, last comment should have been: I would not recomment changing the behavior of the input field from the established standard people are used to in Firefox 2 and IE. my two cents

If the text field is not editable, how can the user remove the reference to some file if he changes his mind?

The user is obligated to send the file?

Pressing delete or backspace should clear the field, IMO. File a bug for that?

(In reply to comment #24)
> Pressing delete or backspace should clear the field, IMO. File a bug for that?
>
Without a focus, editing keys: ^C ^V ^X or Del and BkSp do not work. The only way to be sure that nothing is sent is to have a dummy NIL file and reset the address to that file. (Open button with blank file name does not work either.)
:)

Hmm, the text field can be focused using the mouse but not the keyboard.

Ing0R (ing0r) wrote :

Binary package hint: firefox

Firefox 3 (3.0~b4+nobinonly-0ubuntu1) immediately opens a "file upload" dialog when I click on the file name field. Ff should only open this dialog if click on [Browse...]. Even after I close the dialog window I can neither input a file name directly into the field nor can I remove the file from the input field.
It should be as easy editable as in firefox 2.

I use Hardy amd64.

I'd like to address the issue of cancelling file upload, but I can't think of a discoverable way to clear the filename.

Clearing it on cancel from the filepicker is pretty non-discoverable, eh?

I wonder how Safari handles this (if at all).

Delete/Backspace could clear the field even when the button has focus.

I can't find a way to clear a file upload field in Safari on Tiger.

Pressing Delete when the button has focus isn't very discoverable since that key would normally do nothing when a button is focused, so users probably won't press it. Backspace is even worse since that would normally go back in the history.

Clearing it on cancel from the filepicker would probably be fine for discoverability, since users wanting to clear the field will probably activate the filepicker (on purpose or by accident) and then hit "cancel" when it doesn't help them. But that breaks the normal semantics of "cancel" and could cause users to accidentally clear fields and possibly submit forms with unexpectedly empty fields.

same here with firefox 3.0~b5+nobinonly-0ubuntu3 on hardy under kde 3. looked around in about:config, but couldn't find a way to change that behaviour.

Pio (dromdair) wrote :

Same for me. There should at least be a mean to change one's mind and remove the file to not specify anything !

On Sat, May 31, 2008 at 12:30:50PM -0000, Pio wrote:
> Same for me. There should at least be a mean to change one's mind and
> remove the file to not specify anything !
>

ffox 2 wont see any fixes anymore

 affects ubuntu/firefox
 status wontfix

ffox 3 should get the proper upstream bug associated. Its most likely
set wontfix there, but i am sure bugzilla.mozilla.org has that
fix. get the proper bug id and post here.

 affects xulrunner
 status incomplete

 affects ubuntu/firefox-3.0
 status incomplete

 - Alexander

Changed in firefox:
status: New → Won't Fix
Changed in firefox-3.0:
status: New → Incomplete
Peter Petrov (petersvp) wrote :

This happens in the Windows Version, too!

This affects alternate input projects like Steve Lee's Jambu on screen keyboard. A screen reader developer also recently complained about the FOCUSABLE state on the file input's text field -- basically screen readers are alternative input technologies as well.

I'm not sure if the intent of this bug is to fix more than the a11y API mapping. If so it should be split into several bugs.

Here are the a11y API problems:
When you click in the text field it does get focus for a brief moment, before forwarding focus somewhere else, but that seems to be a hack on our part. It's not really supposed to be focusable.
As a result of it actually being focusable internally it,
1) ends up with the FOCUSABLE state.
2) it can get the FOCUSED state sometimes (not sure exactly when)
3) we're firing a11y API focus events on the field

This is of course all wrong -- we should fix this in the widget implementation and not try to wallpaper around it in a11y API code. The actual control should not actually be focusable -- just handle the onclick but not be in the focus order.

(In reply to comment #31)
> 2) it can get the FOCUSED state sometimes (not sure exactly when)
After cancelling the filepicker.

Here's how I propose fixing it:
Change nsHTMLInputElement::IsHTMLFocusable(PRBool *aIsFocusable, PRInt32 *aTabIndex)
so that it returns *aTabIndex = -1 and PR_FALSE when mType == NS_FORM_INPUT_TEXT and the node is anonymous, and the binding parent content is <input type="file">:
http://mxr.mozilla.org/seamonkey/source/content/html/content/src/nsHTMLInputElement.cpp#2904

Then change onclick for the same situation so that it forwards the click to the file input's button.

Created an attachment (id=327924)
wip

If I get correctly the actual problem is the upload's text field is focusable but when it's focused by click then filepicker dialog is appeared. That confuses screen readers.

The text field must be focusable otherwise AT can have difficulties to read its content (Marco, please correct me if I'm wrong) and users can have troubles as well if its content is too long (more than size of text filed). So they should to "click" text field, close filepicker dialog and then they can read. I would suggest to remove the click handler showing the filepicker dialog for the text field. That should fix the problem. How does it sound?

Phillip Susi (psusi) on 2008-11-26
Changed in firefox-3.0:
status: Incomplete → Confirmed
Micah Gersten (micahg) on 2009-05-21
Changed in xulrunner:
importance: Undecided → Unknown
status: Incomplete → Unknown
Changed in xulrunner:
status: Unknown → Confirmed
Changed in firefox-3.0 (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Triaged
Micah Gersten (micahg) on 2009-08-02
Changed in firefox-3.5 (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Phillip Susi (psusi) on 2010-04-06
Changed in firefox-3.0 (Ubuntu):
status: Triaged → Won't Fix
Changed in firefox-3.5 (Ubuntu):
status: Triaged → Won't Fix
Changed in xulrunner:
importance: Unknown → High
35 comments hidden view all 115 comments

Comment on attachment 710783
Patch

Mounir, it's better ask Marco to give a try with screen readers. Btw, it'd be great if you provide a try build.

Comment on attachment 710783
Patch

btw, this patch would need a fix on a11y side to make a11y mochitests pass

(In reply to alexander :surkov from comment #67)
> Comment on attachment 710783
> Patch
>
> btw, this patch would need a fix on a11y side to make a11y mochitests pass

For the moment, I haven't seen any a11y test failure. Do you know which tests could fail?

(In reply to alexander :surkov from comment #66)
> Comment on attachment 710783
> Patch
>
> Mounir, it's better ask Marco to give a try with screen readers. Btw, it'd
> be great if you provide a try build.

https://<email address hidden>/

Comment on attachment 710783
Patch

> // Mark the element to be native anonymous before setting any attributes.
> mTextContent->SetNativeAnonymous();

That part really needs to be before the SetAttr!

r=me with that fixed

(In reply to Mounir Lamouri (:mounir) from comment #68)
> (In reply to alexander :surkov from comment #67)
> > Comment on attachment 710783
> > Patch
> >
> > btw, this patch would need a fix on a11y side to make a11y mochitests pass
>
> For the moment, I haven't seen any a11y test failure. Do you know which
> tests could fail?

Do I understand correct that you replaced anonymous html:input to xul:label?

(In reply to alexander :surkov from comment #70)
> (In reply to Mounir Lamouri (:mounir) from comment #68)
> > (In reply to alexander :surkov from comment #67)
> > > Comment on attachment 710783
> > > Patch
> > >
> > > btw, this patch would need a fix on a11y side to make a11y mochitests pass
> >
> > For the moment, I haven't seen any a11y test failure. Do you know which
> > tests could fail?
>
> Do I understand correct that you replaced anonymous html:input to xul:label?

Indeed because xul:label supports ellipsis in the middle (with @crop) but CSS do not support that.

Comment on attachment 710783
Patch

This patch removes the read-only input that holds the path and name of the chosen file. In a regular nightly build, this is accessible to both JAWS and NVDA. In the try build, using the first testcase above, or any other file input, the path and file name are no longer accessible. All that remains after choosing a file is the "Browse..." button, as if no file had been chosen yet. Denying feedback.

(In reply to Marco Zehe (:MarcoZ) from comment #72)
> Comment on attachment 710783
> Patch
>
> This patch removes the read-only input that holds the path and name of the
> chosen file. In a regular nightly build, this is accessible to both JAWS and
> NVDA. In the try build, using the first testcase above, or any other file
> input, the path and file name are no longer accessible. All that remains
> after choosing a file is the "Browse..." button, as if no file had been
> chosen yet. Denying feedback.

the fix will be rather on a11y side but I agree this shouldn't go until we have accessibility solution for this.

Jamie, I think we need your help. Can you take a look please at try build:
https://<email address hidden>/
and say how we should expose the input@type="file" to AT to make it working with NVDA?

There are two issues:
- the button is now on the left instead of the right, it is the first child instead of the second;
- the value is shown in a xul:label instead of a html:input which changes a few stuff especially its role is no longer "ENTRY".

BTW, do we have to expose the anonymous nodes to the accessible document? It seems that regarding a11y, it would be as good to simply have one element that has some value and can be open (popup state?). I don't know much about a11y so I might be missing some reasons why we expose those anonymous nodes.

(In reply to Mounir Lamouri (:mounir) from comment #75)
> BTW, do we have to expose the anonymous nodes to the accessible document?

it depends, we expose them when we need them

> It
> seems that regarding a11y, it would be as good to simply have one element
> that has some value and can be open (popup state?). I don't know much about
> a11y so I might be missing some reasons why we expose those anonymous nodes.

the idea is to keep a11y closer to the UI, what the user sees on the screen he hears the same by screen reader. It doesn't necessary contradicts to what you said though. I'm certain we need to have that 'Browse' button, mapping of all other controls can vary I guess.

Changed in xulrunner:
importance: High → Medium
status: Confirmed → In Progress

(In reply to alexander :surkov from comment #73)
> Jamie, I think we need your help. Can you take a look please at try build:
> and say how we should expose the input@type="file" to AT to make it working
> with NVDA?
The problem is that XUL labels expose the IAccessibleText interface, but the text is empty (IAccessibleText::nCharacters returns 0). If the label text is exposed via IAccessibleText, it should work correctly. Alternatively, you can stop exposing IAccessibleText for these labels altogether, but we'd need to discuss this, as NVDA currently won't fall back to accName for labels.

(In reply to James Teh [:Jamie] from comment #77)
> (In reply to alexander :surkov from comment #73)
> > Jamie, I think we need your help. Can you take a look please at try build:
> > and say how we should expose the input@type="file" to AT to make it working
> > with NVDA?
> The problem is that XUL labels expose the IAccessibleText interface, but the
> text is empty (IAccessibleText::nCharacters returns 0). If the label text is
> exposed via IAccessibleText, it should work correctly.

If we would expose IAccessibleText correctly then would it fix a problem?

Mounir, I assume you use @value attribute on that xul:label. Is it possible to switch to text node instead?

> Alternatively, you
> can stop exposing IAccessibleText for these labels altogether, but we'd need
> to discuss this, as NVDA currently won't fall back to accName for labels.

I'd be great if we end up here having an optimal solution for user experience.

To clarify, there are two solutions:
1. Expose the text correctly via IAccessibleText; or
2. Stop exposing IAccessibleText altogether on that object (i.e. QueryInterface shouldn't return it). To work with current NVDA, the text would have to be exposed as the value rather than the name if the role is label. We can debate this name/value point, but it's not worth discussing if option 1 is suitable.

(In reply to alexander surkov from comment #78)
> Mounir, I assume you use @value attribute on that xul:label. Is it possible
> to switch to text node instead?
He can't *switch* to text node because he requires the crop behaviour, but I believe the value attribute takes priority over the text node so that if he provides both then it will show cropped text but obviously I don't know whether the accessibility code will see the text node. (Is it possible to query the accessible tree in DOM Inspector to find out?)

(In reply to <email address hidden> from comment #80)
> (In reply to alexander surkov from comment #78)
> > Mounir, I assume you use @value attribute on that xul:label. Is it possible
> > to switch to text node instead?
> He can't *switch* to text node because he requires the crop behaviour, but I
> believe the value attribute takes priority over the text node so that if he
> provides both then it will show cropped text but obviously I don't know
> whether the accessibility code will see the text node. (Is it possible to
> query the accessible tree in DOM Inspector to find out?)

I tried that and that unfortunately doesn't work :(

(In reply to alexander :surkov from comment #78)
> (In reply to James Teh [:Jamie] from comment #77)
> > (In reply to alexander :surkov from comment #73)
> > > Jamie, I think we need your help. Can you take a look please at try build:
> > > and say how we should expose the input@type="file" to AT to make it working
> > > with NVDA?
> > The problem is that XUL labels expose the IAccessibleText interface, but the
> > text is empty (IAccessibleText::nCharacters returns 0). If the label text is
> > exposed via IAccessibleText, it should work correctly.
>
> If we would expose IAccessibleText correctly then would it fix a problem?
>
> Mounir, I assume you use @value attribute on that xul:label. Is it possible
> to switch to text node instead?

I'm using xul:label because there is the crop feature.

(In reply to <email address hidden> from comment #80)
> (In reply to alexander surkov from comment #78)
> > Mounir, I assume you use @value attribute on that xul:label. Is it possible
> > to switch to text node instead?
> He can't *switch* to text node because he requires the crop behaviour, but I
> believe the value attribute takes priority over the text node so that if he
> provides both then it will show cropped text but obviously I don't know
> whether the accessibility code will see the text node.

Do you mean
<xul:label value="file:///c:/path-to-file">file:///c:/path-to-file</xul:label>
?

but then if @value takes precedence and it gets cropped then it'd be great if text node would be the same as representation of @value attribute. That doesn't happen I assume.

So crop doesn't give desired effect on
<xul:label>file:///c:/path-to-file</xul:label>
or
<xul:description>file:///c:/path-to-file</xul:description>

> (Is it possible to
> query the accessible tree in DOM Inspector to find out?)

sure, just switch to Accessible Tree viewer in left panel and inspect the accessible tree.

(In reply to alexander :surkov from comment #82)
> (In reply to <email address hidden> from comment #80)
> So crop doesn't give desired effect on
> <xul:label>file:///c:/path-to-file</xul:label>
> or
> <xul:description>file:///c:/path-to-file</xul:description>

None of those worked.

How is @value attribute implemented on xul:label? They don't create a native anonymous content for it, correct?

(In reply to alexander :surkov from comment #84)
> They don't create a native anonymous content for it, correct?

AFAICT, that's correct.

(In reply to James Teh [:Jamie] from comment #79)

> 2. Stop exposing IAccessibleText altogether on that object (i.e.
> QueryInterface shouldn't return it). To work with current NVDA, the text
> would have to be exposed as the value rather than the name if the role is
> label. We can debate this name/value point, but it's not worth discussing if
> option 1 is suitable.

Jamie, regardless of this bug, is this worth doing? (If yes let's get a bug filed)

(In reply to David Bolter [:davidb] from comment #86)
> > 2. Stop exposing IAccessibleText altogether on that object (i.e.
> > QueryInterface shouldn't return it). To work with current NVDA, the text
> > would have to be exposed as the value rather than the name if the role is
> > label.
> Jamie, regardless of this bug, is this worth doing? (If yes let's get a bug
> filed)
The controversial point is exposing the label text as the value instead of the name, as this will break ATs that rely on the label text being the name. My understanding is that a decision hasn't yet been made as to whether to expose the text properly via IAccessibleText. If the answer to that is yes, we don't have to worry about this at all.

I heard from Alex and we can work out the a11y fix/followup separately. Note uplift is Tuesday...

(In reply to David Bolter [:davidb] from comment #88)
> I heard from Alex and we can work out the a11y fix/followup separately. Note
> uplift is Tuesday...

We can't ship Firefox breaking hardly the accessibility of HTML controls. So the fix must be at least on Beta. Having broken HTML file input on nightly and aurora is a bad thing too since we likely loose testers using nighties as daily browser (I think Marco is one of them). But probably that's acceptable if it doesn't take too long.

If uplifting is Thuesday then we likely get inaccessible nightly and aurora both for uncertain period because we still don't have working a11y solution. I would land this patch after uplifting.

In the meantime I'll try to get a11y patch on top of Mounir's patch.

Alexander, is there any way I can help? Do you want me to send you a folded patch with all changes related to this (this patch might not apply cleanly on top af tip)?

(In reply to Mounir Lamouri (:mounir) from comment #90)
> Alexander, is there any way I can help? Do you want me to send you a folded
> patch with all changes related to this (this patch might not apply cleanly
> on top af tip)?

yes, it doesn't apply cleanly. something to apply it would be great

(In reply to alexander :surkov from comment #91)
> (In reply to Mounir Lamouri (:mounir) from comment #90)
> > Alexander, is there any way I can help? Do you want me to send you a folded
> > patch with all changes related to this (this patch might not apply cleanly
> > on top af tip)?
>
> yes, it doesn't apply cleanly. something to apply it would be great

I just sent you a patch that should apply on tip.

Mounir, can you upload a new try build and ask Marco for feedback pls (since bug 396166 is fixed)?

Comment on attachment 710783
Patch

Marco, could you try this build and tell us if <input type='file'> are okay regarding a11y:
https://<email address hidden>/

Thanks :)

Comment on attachment 710783
Patch

Cancelling feedback request because the accessibility implications are being taken care of in a separate bug.

Changed in xulrunner:
status: In Progress → Fix Released

for documentation see also bug 52500

The 'simple text' is unusable when on a black or dark background. To make file inputs usable (and there are many, many sites for which file inputs are an essential part of their functionality) for sites with dark or black backgrounds now requires some non-obvious CSS and targetting for Firefox 22 and no other browser. Firefox is effectively unusable for sites with dark backgrounds and file inputs. PLEASE revert to the previous treatment of file inputs as soon as possible. I considered simply changing browser and telling everyone I know to do so too, but it occurred to me that I owed Firefox more than that.
Let me restate: file inputs are effectively BROKEN for use on sites with dark backgrounds.

Would you mind please to file separate bug on it (cc Mounir and me)?

Geoff K,

This is not an issue. The required CSS is simple and obvious:

<!DOCTYPE html>
<html>
<head>
<style>

  body {background:black}
  #myfile {color:white}

</style>
</head>
<body>
<input id="myfile" type="file">
</body>
</html>

(In reply to geoffk from comment #99)

Bug 874600 is supposed to have fixed that problem (and the test case there works correctly in Fx 22).

No, ic3b3rg, the fix is far from obvious - and certainly not that obvious. Text inputs have a white background by default, so dark text shows up in them. White text on #myfile would make all other text input invisible. That leaves us needing to provide white text for input[type='file'], but dark text for all other browsers and previous versions of FF - far more complicated than you seem to think, and who knew that there was going to be a need to cater for this? In a nutshell, the new input[type='file'] is writing outside the box so this particular input type on (recent versions only of...!) this particular browser would need to be a different color to all other inputs. The best fix is not to change font color at all; instead, put a background-color on all inputs, including the file uploads:

input {background-color: #FFF}

This puts a white background behind the text of all inputs, including FF22/23. Do you want to tell the rest of the world they need to do that, on future sites and existing ones, or is it perhaps best to make #FFF the default background for future releases of FF input[type='file'] ?

Philippe, the test case has a background-color of #FFF applied to it in CSS. If the test case had a black background on the form and the CSS had not been written to compensate, the writing would be invisible. That is exactly as now (not) being seen on any dark-backgrounded sites with a file upload... unless browsing with something other than FF22/23, in which case it continues to be as readable as ever. Inside a form input is light, or dark, and you set CSS to contrast with that background. If 'input' text starts being written outside the input box, which is often dark when the input box is light, and vice versa, the contrast will often be dramatically reduced to the point that you cannot see the text.
Summary - you need to show text against the same background tone for an input[file] as for all other inputs, default being white. You can't rely on having the same background outside of a box as inside.

Note, Geoff filed bug 890252 for the issue. Let's keep discussion there.

Displaying first 40 and last 40 comments. View all 115 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.