<input type=file> does not accept textual input

Bug #209509 reported by Ing0R
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
XULRunner
Fix Released
Medium
firefox (Ubuntu)
Won't Fix
Undecided
Unassigned
firefox-3.0 (Ubuntu)
Won't Fix
Medium
Unassigned
firefox-3.5 (Ubuntu)
Won't Fix
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.

Revision history for this message
In , Aaronleventhal (aaronleventhal) wrote :

Created an attachment (id=229814)
Testcase

Revision history for this message
In , Gavin Sharp (gavin-sharp) wrote :

This was changed in bug 258875.

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

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

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

Revision history for this message
In , L. David Baron (dbaron) wrote :

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?

Revision history for this message
In , Alexander Surkov (surkov-alexander) wrote :

(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.

Revision history for this message
In , Aaronr-us (aaronr-us) wrote :

(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.

Revision history for this message
In , Jonas-sicking (jonas-sicking) wrote :

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.

Revision history for this message
In , Aaronr-us (aaronr-us) wrote :

(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.

Revision history for this message
In , Dveditz (dveditz) wrote :

(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.

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

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

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

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

Revision history for this message
In , SteveLee (steve-fullmeasure) wrote :

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.

Revision history for this message
In , Aaronleventhal (aaronleventhal) wrote :

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.

Revision history for this message
In , Roc-ocallahan (roc-ocallahan) wrote :

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.

Revision history for this message
In , SteveLee (steve-fullmeasure) wrote :

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

Revision history for this message
In , SteveLee (steve-fullmeasure) wrote :

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.

Revision history for this message
In , Roc-ocallahan (roc-ocallahan) wrote :

Aaron, can you make the accessibility change here?

Revision history for this message
In , Roc-ocallahan (roc-ocallahan) wrote :

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

Revision history for this message
In , Parkhideh (parkhideh) wrote :

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.

Revision history for this message
In , Gibsonb (gibsonb) wrote :

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

Revision history for this message
In , Gibsonb (gibsonb) wrote :

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.

Revision history for this message
In , Gibsonb (gibsonb) wrote :

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

Revision history for this message
In , Fernando P Silveira (fernandopsilveira) wrote :

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?

Revision history for this message
In , Jruderman (jruderman) wrote :

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

Revision history for this message
In , Parkhideh (parkhideh) wrote :

(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.)
:)

Revision history for this message
In , Jruderman (jruderman) wrote :

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

Revision history for this message
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.

Revision history for this message
In , Roc-ocallahan (roc-ocallahan) wrote :

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

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

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

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

Revision history for this message
In , Jruderman (jruderman) wrote :

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.

Revision history for this message
In , Roc-ocallahan (roc-ocallahan) wrote :

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.

Revision history for this message
georg wiltschek (georg-wiltschek) wrote :

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.

Revision history for this message
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 !

Revision history for this message
Alexander Sack (asac) wrote : Re: [Bug 209509] Re: <input type=file> does not accept textual input

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
Revision history for this message
Peter Petrov (petersvp) wrote :

This happens in the Windows Version, too!

Revision history for this message
In , Aaronleventhal (aaronleventhal) wrote :

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.

Revision history for this message
In , Neil-httl (neil-httl) wrote :

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

Revision history for this message
In , Aaronleventhal (aaronleventhal) wrote :

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.

Revision history for this message
In , Alexander Surkov (surkov-alexander) wrote :

Created an attachment (id=327924)
wip

Revision history for this message
In , Alexander Surkov (surkov-alexander) wrote :

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)
Changed in firefox-3.0:
status: Incomplete → Confirmed
Micah Gersten (micahg)
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)
Changed in firefox-3.5 (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Phillip Susi (psusi)
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
Revision history for this message
In , Alexander Surkov (surkov-alexander) wrote :

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.

Revision history for this message
In , Alexander Surkov (surkov-alexander) wrote :

Comment on attachment 710783
Patch

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

Revision history for this message
In , Mounir (mounir) wrote :

(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>/

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

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

Revision history for this message
In , Alexander Surkov (surkov-alexander) wrote :

(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?

Revision history for this message
In , Mounir (mounir) wrote :

(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.

Revision history for this message
In , Marco-zehe (marco-zehe) wrote :

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.

Revision history for this message
In , Alexander Surkov (surkov-alexander) wrote :

(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?

Revision history for this message
In , Mounir (mounir) wrote :

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".

Revision history for this message
In , Mounir (mounir) wrote :

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.

Revision history for this message
In , Alexander Surkov (surkov-alexander) wrote :

(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
Revision history for this message
In , James Teh (jteh) wrote :

(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.

Revision history for this message
In , Alexander Surkov (surkov-alexander) wrote :

(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.

Revision history for this message
In , James Teh (jteh) wrote :

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.

Revision history for this message
In , Neil-httl (neil-httl) wrote :

(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?)

Revision history for this message
In , Mounir (mounir) wrote :

(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.

Revision history for this message
In , Alexander Surkov (surkov-alexander) wrote :

(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.

Revision history for this message
In , Mounir (mounir) wrote :

(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.

Revision history for this message
In , Alexander Surkov (surkov-alexander) wrote :

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

Revision history for this message
In , Mounir (mounir) wrote :

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

AFAICT, that's correct.

Revision history for this message
In , Dbolter (dbolter) wrote :

(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)

Revision history for this message
In , James Teh (jteh) wrote :

(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.

Revision history for this message
In , Dbolter (dbolter) wrote :

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

Revision history for this message
In , Alexander Surkov (surkov-alexander) wrote :

(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.

Revision history for this message
In , Mounir (mounir) wrote :

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)?

Revision history for this message
In , Alexander Surkov (surkov-alexander) wrote :

(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

Revision history for this message
In , Mounir (mounir) wrote :

(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.

Revision history for this message
In , Alexander Surkov (surkov-alexander) wrote :

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

Revision history for this message
In , Mounir (mounir) wrote :

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 :)

Revision history for this message
In , Marco-zehe (marco-zehe) wrote :

Comment on attachment 710783
Patch

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

Revision history for this message
In , Mounir (mounir) wrote :
Revision history for this message
In , Ryanvm (ryanvm) wrote :
Changed in xulrunner:
status: In Progress → Fix Released
Revision history for this message
In , Moz-jeka (moz-jeka) wrote :

for documentation see also bug 52500

Revision history for this message
In , Geoffk-9 (geoffk-9) wrote :

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.

Revision history for this message
In , Alexander Surkov (surkov-alexander) wrote :

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

Revision history for this message
In , Ic3b3rg (ic3b3rg) wrote :

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>

Revision history for this message
In , Phiw (phiw) wrote :

(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).

Revision history for this message
In , Geoffk-9 (geoffk-9) wrote :

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'] ?

Revision history for this message
In , Geoffk-9 (geoffk-9) wrote :

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.

Revision history for this message
In , Alexander Surkov (surkov-alexander) wrote :

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  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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