89689 - readonly textarea and input text controls should indicate receiving focus

Status: VERIFIED DUPLICATE of bug 193316

(Core :: Layout: Form Controls, defect, P3)

Description

[Madhur Bhatia]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010703 
Netscape6/6.1 

steps to reproduce:
1. open attached testcase
2. do TAB navigation

actual:
I have set the readonly attribute for <input type=text> and <textarea> controls.
when i tab through the conrols, i notice that all the controls(whether they have 
a readonly attribute set or not) receive focus.
But the controls which have the readonly attribute set, do not show any 
indication whether it has received focus or not. **But actually, these controls 
have also received focus. If i do an onfocus event for these controls, i'll see 
that they receive focus**


These controls are following the notes in 
http://www.w3.org/TR/html4/interact/forms.html#h-17.12.2

expected:
When the readonly control receives focus via tabbing, there should be some 
indication showing the user that the control has been selected. 
Something like highlighting the control/or the contents of the control would be 
helpful.

what i see in IE:
when the <input type=text> control, which has a readonly attribute set, receives 
focus - the text within the textbox is highlighted.
The textarea control still does not show any indication of receiving focus.

what would be nice:
it would be user friendly if we added this feature to our browser.

Comment 1

[Madhur Bhatia]

Attachment: testcase

Comment 2

[Warner Young]

I actually think the system in Windows is fairly good.  Readonly text fields
have a different colored background, and the text itself is greyed out.  You
can't change the contents, but you *can* see the text caret, which is at least a
reasonably good indication of focus.

Comment 3

[Madhur Bhatia]

in window2000
1. i do not see the text within the controls greyed out
2. upon focus, I do *not see* the text caret, as well.

If either of these indications were there, it would have been good. But they are 
not.
 

Comment 4

[Warner Young]

Oops.  I should have said, the system in native text controls in Windows.  Not
to imply that Mozilla in Windows does what I said.

Comment 5

[rods (gone)]

->>

Comment 6

[kinmoz]

Bulk move of mozilla1.0 bugs to mozilla.1.0.1. I will try to pull some of these
back in if I can.

Comment 7

[Jesse Ruderman]

Dup of bug 108291?

Comment 8

[Mike Kaply [:mkaply]]

Attachment: Fix for problem

The fix for this is just to remove an if statement.

Note the cursor not appearing in textareas at first is a totally different
problem. I think it is 122311 or 144630

Comment 9

[kinmoz]

Comment on attachment 87225 [details] [diff] [review]
Fix for problem

This patch will cause the caret to show up in readonly fields. You can't do
that because the caret is an indicator to the user that they can input data.

Comment 10

[Mike Kaply [:mkaply]]

No, it's an indicator that it is text. And they can do things. Like select, and 
cut, etc.

There needs to be a cursor in any entryfield.

Comment 11

[Charles Manske]

*** Bug 108291 has been marked as a duplicate of this bug. ***

Comment 12

[[e-mail]]

MailNews needs this for their selectable header fields (bug 61497 comment 120).

Comment 13

[Gérard Talbot]

Is this bugfile still active? The testcase (attachment 41466 [details]) WORKSFORME.
XP Pro SP1, Mozilla 1.5 build 20031007 here.

Comment 14

[[e-mail]]

If that's the case then let's see a screenshot of your mozilla with the caret
between the two n's of "Cannot".

Comment 15

[Gérard Talbot]

I uninstall 1.5 and install 1.6beta (2003120808) and tried the testcase again
(attachment 41466 [details]).

The readonly textarea gets the focus (via tab): I can see this because of the
inner border becomes dotted 1px (possibly/most likely because of a default
declaration like -moz-outline: 1px dotted black). The caret is not visible in
the textarea. I tried to insert the caret between the 2 n's of "Cannot" and
still could not see the caret. I can select (mouse drag, highlighting or Ctrl+A
[or select all via right-click contextmenu]) any substring of this readonly
textarea.

The readonly input type="text" gets focus: its content gets selected (reverse
video) and the inner border gets dotted 1px when I tab to it. When I click
inside that readonly input, the inner border again gets dotted 1px but the caret
is not visible. I can select (mouse drag, highlighting) any substring of the input.

I wish that the expected results and/or the testcase itself would have mention
the need to have the caret visible for these readonly form controls. MSIE 6 SP2
for Windows fails too to show the caret in readonly elements. Right now, I would
say that Mozilla 1.6beta handles better this issue of viual notification of
focused readonly form input elements. In MSIE 6 SP2 for windows, the text in
readonly form input elements is not greyed out, I can not see the caret and I do
not see an outline border around the element upon receiving focus.

Finally, I feel that rendering a caret for readonly form input elements can be
confusing: it kinda suggest you can insert, add text at the caret position more
than it suggests you can select text. 
My 2 cents.

Comment 16

[Warner Young]

Although IE doesn't always show a caret in a readonly field, Windows itself
does.  Also, using Moz Firebird build 20031211, I don't see a 1-pixel dotted
outline at all on the readonly fields when they get focus.

Comment 17

[Gérard Talbot]

Thank you for reporting this back. 
I checked again and I had 
user_pref("browser.display.focus_ring_on_anything", true); 
in my user.js. I was aware of this and changed it to false before testing but
that did not update the prefs.js file accordingly. So this is an unfortunate
error on my part. Sorry. So, no, there is no 1px dotted outline border around
the readonly elements when they get focus ... unless, of course, you have the
display.focus_ring_on_anything" prop. set to true.

Comment 18

[Martijn Wargers (dead)]

This was fixed in bug 193316, so I'm marking this a duplicate of that bug.

*** This bug has been marked as a duplicate of 193316 ***