The default bug view has changed. See this FAQ.

Replace the anonymous <input type='text'> in <input type='file'> by a simple text

RESOLVED FIXED in mozilla22

Status

()

Core
Layout: Form Controls
RESOLVED FIXED
11 years ago
4 years ago

People

(Reporter: Aaron Leventhal, Assigned: mounir)

Tracking

(Depends on: 1 bug, Blocks: 1 bug, {access, dev-doc-needed, regression})

Trunk
mozilla22
access, dev-doc-needed, regression
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 -
wanted1.9 +
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments)

(Reporter)

Description

11 years ago
<input type="file"> controls consist of a textfield and a button. The textfield used to be tabbable, and now it isn't. This makes it difficult for a screen reader user to use the form control (read what file is currently listed there, not to mention realize that it's a file input).

If this behavioral change is intentional, I'm not sure why. It makes us different from the other browsers in a less accessible way. Being able to type in the filename without using the file picker is a good thing.
(Reporter)

Comment 1

11 years ago
Created attachment 229814 [details]
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?
Blocks: 258875
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?

Comment 5

11 years ago
(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.

Comment 6

11 years ago
(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.

Comment 8

11 years ago
(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".

Updated

11 years ago
Blocks: 356071
I think we should consider moving forward with that more mac-like control...
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9+

Comment 12

10 years ago
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.
(Reporter)

Comment 13

10 years ago
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.
Whiteboard: [dbaron-1.9:RuCs]
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.

Comment 15

10 years ago
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

Comment 16

10 years ago
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?
Priority: -- → P4
(Reporter)

Updated

10 years ago
Blocks: 396346
Assigning to Aaron for now. This bug will fall off the blocking list if someone doesn't pick it up soon.
Assignee: nobody → aaronleventhal

Comment 19

9 years ago
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.

Comment 20

9 years ago
Created attachment 304786 [details]
file to test setting focus to an input type=file field programmatically

Comment 21

9 years ago
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.  

Comment 22

9 years ago
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?

Comment 24

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

Comment 25

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

Comment 26

9 years ago
Hmm, the text field can be focused using the mouse but not the keyboard.
Flags: wanted1.9+
Flags: blocking1.9-

Updated

9 years ago
Flags: tracking1.9+
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).

Comment 29

9 years ago
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.
(Reporter)

Updated

9 years ago
Assignee: aaronleventhal → surkov.alexander
(Reporter)

Comment 31

9 years ago
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.
(Reporter)

Comment 33

9 years ago
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.

Comment 34

9 years ago
Created attachment 327924 [details] [diff] [review]
wip

Comment 35

9 years ago
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?
Yes, that sounds good! The textfield containing the file name is marked read-only anyway, so being able to focus it actually does not entail danger of edits anyway. And being able to focus it to review its contents would be a great help esp for Orca which does not use a virtual buffer.

Comment 37

9 years ago
(In reply to comment #35)
> 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. 

It also confuses me ;-) 

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

Sounds good. I think the keyboard, mouse and a11y should have similar behaviours as far as the popup is concerned.
That sounds like a functionality regression for users to me.  Better to drop the textfield altogether and just have text there without a disabled input.

Comment 39

9 years ago
(In reply to comment #38)
> That sounds like a functionality regression for users to me.  Better to drop
> the textfield altogether and just have text there without a disabled input.
> 

That should be much similar with Safari's upload control. Marco, how does it sound from the point of view of a11y?
As long as the file name/path is visible once someone okays the "Browse" dialog, I'm fine with it. Virtual Buffers, as used in the Windows screen readers, can copy & paste plain text as well as text within a textbox, so if this text is within normal text I don't have any problem with it, either.

Comment 41

9 years ago
So visually you have to deal with long paths with ... in the middle, tooltips or some other technique. If they are readonly edit boxes they can be hscrolled (even if styled to look like text as Windows does in file property dialogs; strangely I just tried Nautilus and though it lets you move the caret you cant hscroll and it ends with ...)

Comment 42

9 years ago
Safari's upload shows the file name only and if file name is big then it shows the start and the end of name only. Tooltip can be good. Is it ok to follow the Safari's control?

Comment 43

9 years ago
document.getElementById("afile").focus() seem to be broken in firefox 3.0.1 I'm not sure for 3.0 version but in 2.0.x it worked. Focus by mouse or keyboard in tab order is ok. By the way it's cool that in 3 version textbox to the left of button getting no focus in tab order.  

Updated

9 years ago
Duplicate of this bug: 453377

Comment 45

9 years ago
(In reply to comment #43)
> document.getElementById("afile").focus() seem to be broken in firefox 3.0.1 I'm
> not sure for 3.0 version but in 2.0.x it worked. Focus by mouse or keyboard in
> tab order is ok. By the way it's cool that in 3 version textbox to the left of
> button getting no focus in tab order.  

yes, I can approve that.
The behaviour is different on every version and should be like on any other form-field.

Firefox 1.0, 1.5, 2.0:
- focus() works for cursor but view will not scroll to where the field is embedded in

Firefox 3.0 und 3.1a1:
- as of this version, neither scrolling nor cursor focus works


fyi:
in Opera 9.5:
scrolling works, but not cursor focus

in IE 6 & IE7:
focus() quite good! Cursor and view will be set correctly!
Blocks: 469280
(Reporter)

Comment 46

8 years ago
> *** Bug 453377 has been marked as a duplicate of this bug. ***

Actually it isn't. This bug is about the textfield not taking focus, which is a design choice and probably won't be changed. On the other hand, bug 453377 is about fileInput.focus() not setting focus to the browse button.

Comment 47

8 years ago
Ubuntu Bug:
https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/209509
I've been watching to this bug and still see no solution in case the user changes his mind and wish to remove the file to not specify anything.

Should I file a specific bug for that?

Comment 49

8 years ago
That's covered by bug 431098.

Comment 50

8 years ago
Would it be too bad if this behaviour were configurable via about:config?
I know this was changed to prevent certain security exploits on Firefox - so let's say the default behaviour would be as it is now. However, if the users know what they're doing and want to change it to the way it was on Fx 2.0, they should be allowed to change it. Also, this would automatically fix bug 431098.

Comment 51

8 years ago
These exploits are not the kind where "knowing what you're doing" is sufficient protection.

Comment 52

7 years ago
This sounds absurd.  If a script can jam input into the field without the user's permission and/or awareness, then fix the bug in the script engine; don't deny the user's ability to type in the field.
Phillip, may I suggest reading bug 258875 (all of it), as well as all linked bugs and testcases, before deciding something is absurd?

Updated

7 years ago

Comment 54

7 years ago
I fail to see why you would suggest that.

Find a way to prevent the feature ( typing in the file name ) from being exploited by a malicious web site; don't kill the feature entirely.
> I fail to see why you would suggest that.

Because multiple people literally spent years looking for a way to prevent the feature from being exploited by a malicious website.  They failed to find one.  Which is very, had you bothered to read the bug I cited.

Comment 56

6 years ago
Created attachment 555388 [details]
Testcase for

Someone suggested that I attach this test to this bug.

<input type="file"> is the only type of input that cannot be triggered via a label.
(In reply to Tristan Daeschner from comment #56)
> Created attachment 555388 [details]
> Testcase for
> 
> Someone suggested that I attach this test to this bug.
> 
> <input type="file"> is the only type of input that cannot be triggered via a
> label.

Looks like this is a different bug. You want to trigger the filepicker or focus the "browse…" button with this.

Comment 58

6 years ago
Mounir, would you willing to take a look at this one? I think the approach everybody feels ok is to follow safari's way (it works both for sighted and blind users).
Assignee: surkov.alexander → nobody

Comment 59

6 years ago
I like the idea of going the Safari route :) 

On a related note, will this fix also address the issue of the File input not exposing the aria-label and aria-required attributes that are set on the <input> element? At the moment, these seem to be ignored.
(Assignee)

Comment 60

6 years ago
(In reply to alexander surkov from comment #58)
> Mounir, would you willing to take a look at this one? I think the approach
> everybody feels ok is to follow safari's way (it works both for sighted and
> blind users).

By that you mean removing the text field and have only a simple text?

Comment 61

6 years ago
(In reply to Damian from comment #59)

> On a related note, will this fix also address the issue of the File input
> not exposing the aria-label and aria-required attributes that are set on the
> <input> element? At the moment, these seem to be ignored.

No, could you please file new bug?

Comment 62

6 years ago
(In reply to Mounir Lamouri (:volkmar) (:mounir) from comment #60)
> (In reply to alexander surkov from comment #58)
> > Mounir, would you willing to take a look at this one? I think the approach
> > everybody feels ok is to follow safari's way (it works both for sighted and
> > blind users).
> 
> By that you mean removing the text field and have only a simple text?

right

Comment 63

6 years ago
(In reply to alexander surkov from comment #61)
> (In reply to Damian from comment #59)
> 
> > On a related note, will this fix also address the issue of the File input
> > not exposing the aria-label and aria-required attributes that are set on the
> > <input> element? At the moment, these seem to be ignored.
> 
> No, could you please file new bug?

Sure, here it is: https://bugzilla.mozilla.org/show_bug.cgi?id=699017

Updated

4 years ago
Duplicate of this bug: 834206
(Assignee)

Updated

4 years ago
Summary: File input textfields no longer take focus → Replace the anonymous <input type='text'> in <input type='field'> by a simple text
(Assignee)

Updated

4 years ago
Severity: major → normal
Priority: P4 → --
Summary: Replace the anonymous <input type='text'> in <input type='field'> by a simple text → Replace the anonymous <input type='text'> in <input type='file'> by a simple text
(Assignee)

Comment 65

4 years ago
Created attachment 710783 [details] [diff] [review]
Patch

I had to use a <xul:label> because I needed an ellipsis in the middle of the text.

Alexander, how would that be regarding a11y? Is using a <xul:label> a bad thing?
Assignee: nobody → mounir
Status: NEW → ASSIGNED
Attachment #710783 - Flags: review?(bzbarsky)
Attachment #710783 - Flags: feedback?(surkov.alexander)
(Assignee)

Updated

4 years ago
Blocks: 838675

Comment 66

4 years ago
Comment on attachment 710783 [details] [diff] [review]
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.
Attachment #710783 - Flags: feedback?(surkov.alexander) → feedback?(marco.zehe)

Comment 67

4 years ago
Comment on attachment 710783 [details] [diff] [review]
Patch

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

Updated

4 years ago
Blocks: 762270
(Assignee)

Comment 68

4 years ago
(In reply to alexander :surkov from comment #67)
> Comment on attachment 710783 [details] [diff] [review]
> 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 [details] [diff] [review]
> 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://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mlamouri@mozilla.com-b61257dc2541/
Comment on attachment 710783 [details] [diff] [review]
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
Attachment #710783 - Flags: review?(bzbarsky) → review+

Comment 70

4 years ago
(In reply to Mounir Lamouri (:mounir) from comment #68)
> (In reply to alexander :surkov from comment #67)
> > Comment on attachment 710783 [details] [diff] [review]
> > 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?
(Assignee)

Comment 71

4 years ago
(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 [details] [diff] [review]
> > > 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 [details] [diff] [review]
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.
Attachment #710783 - Flags: feedback?(marco.zehe) → feedback-

Comment 73

4 years ago
(In reply to Marco Zehe (:MarcoZ) from comment #72)
> Comment on attachment 710783 [details] [diff] [review]
> 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://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mlamouri@mozilla.com-b61257dc2541/
and say how we should expose the input@type="file" to AT to make it working with NVDA?
Flags: needinfo?(jamie)
(Assignee)

Comment 74

4 years ago
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".
(Assignee)

Comment 75

4 years ago
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.

Comment 76

4 years ago
(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.

Comment 77

4 years ago
(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.
Flags: needinfo?(jamie)

Comment 78

4 years ago
(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.

Comment 79

4 years ago
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?)
(Assignee)

Comment 81

4 years ago
(In reply to neil@parkwaycc.co.uk 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.

Comment 82

4 years ago
(In reply to neil@parkwaycc.co.uk 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.
(Assignee)

Comment 83

4 years ago
(In reply to alexander :surkov from comment #82)
> (In reply to neil@parkwaycc.co.uk 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.

Comment 84

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

Comment 85

4 years ago
(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)

Comment 87

4 years ago
(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...

Comment 89

4 years ago
(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.
(Assignee)

Comment 90

4 years ago
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)?

Comment 91

4 years ago
(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
(Assignee)

Comment 92

4 years ago
(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.

Updated

4 years ago
Depends on: 396166
(Assignee)

Updated

4 years ago
Blocks: 847233

Comment 93

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

Comment 94

4 years ago
Comment on attachment 710783 [details] [diff] [review]
Patch

Marco, could you try this build and tell us if <input type='file'> are okay regarding a11y:
https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mlamouri@mozilla.com-d7c3eda7996a/

Thanks :)
Attachment #710783 - Flags: feedback- → feedback?(marco.zehe)
Comment on attachment 710783 [details] [diff] [review]
Patch

Cancelling feedback request because the accessibility implications are being taken care of in a separate bug.
Attachment #710783 - Flags: feedback?(marco.zehe)
(Assignee)

Comment 96

4 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/511ea736284e
Flags: in-testsuite+
Whiteboard: [dbaron-1.9:RuCs]
(Assignee)

Updated

4 years ago
Target Milestone: --- → mozilla22
https://hg.mozilla.org/mozilla-central/rev/511ea736284e
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED

Updated

4 years ago
Depends on: 855913
Depends on: 857409
Depends on: 857463

Updated

4 years ago
Depends on: 859714

Comment 98

4 years ago
for documentation see also bug 52500
Keywords: dev-doc-needed

Comment 99

4 years ago
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.

Comment 100

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

Comment 101

4 years ago
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).

Comment 103

4 years ago
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'] ?

Comment 104

4 years ago
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.

Updated

4 years ago
Depends on: 890252

Comment 105

4 years ago
Note, Geoff filed bug 890252 for the issue. Let's keep discussion there.
You need to log in before you can comment on or make changes to this bug.