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.

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.

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.

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

->>

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

Dup of bug 108291?

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

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.

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

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

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

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

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.

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.

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.

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