User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210 When the attached page is viewed the focus marker (the I-bar/cursor) disappears. The problem is the "inputElement.readOnly = true" statement. If this is removed then it works. Even though the I-bar disappears text is still entered the right place. Reproducible: Always Steps to Reproduce:

Over to aaronl... Happens on current linux trunk too.

Basic HTML widget -> major

feel free to show us a patch for evaluation but we're not going to block on this failure.

The condition to avoid enabling the caret for the readonl editor goes back to a checkin by Buster in v1.77 of that file.

I take it that the caret shows up, but does not blink with this patch?

(In reply to comment #7) > I take it that the caret shows up, but does not blink with this patch? That's right. And I tested to make sure it doesn't get stuck in a nonblinking state. Once you go back to an editable field it blinks again.

Comment on attachment 197947 [details] [diff] [review] Enable readonly caret for readonly editors This works great in HTML, but for some reason it doesn't quite work in XUL; I am experiencing two issues: a) when an existing selection in a textbox is collapsed for some reason (e.g. pressing an arrow key) the caret does not appear. b) when clicking on a readonly textbox the caret does not appear, nor does it disappear from the previous textbox! If you go on to click in a third readonly textbox it then appears where you originally clicked in the second textbox and so on. Note that subsequent arrow keys or clicks in the same textbox show the readonly caret correctly.

Comment on attachment 197947 [details] [diff] [review] Enable readonly caret for readonly editors I'm not a qualified reviewer for this code. Please have an editor peer review, ok?

Neil, the main problem that I'm seeing is that the mouse is somehow affecting the caret.

1) Make sure the caret's readonly status is set before we enable it, because that affects whether PrimeTimer() does anything 2) When caret is erased via EraseCaret() prior to painting, make sure it gets redisplayed when it was readonly and didn't have a blink timer. We do this by reusing the blink timer for a one shot timer with length 0 3) In StartBlinking() the selection is sometimes not set yet causing the initial draw to fail. When it's a blinking caret it's hard to notice that because eventually the caret gets drawn anyway. For the readonly caret we need to make sure it gets drawn after the selection. I just reused the brief one shot timer trick to make sure this happens after the selection had to be set. That might be hacky but what's a clean way that doesn't change a lot of code?

Comment on attachment 198272 [details] [diff] [review] Resolves XUL textbox problems but we probably need something less hacky. Open to suggestions. Sorry, I don't know caret code, try mrbkap or glazou?

Comment on attachment 198272 [details] [diff] [review] Resolves XUL textbox problems but we probably need something less hacky. Open to suggestions. I guess this is OK if you're trying to get this into the branch, but we should really try to find a better way to do this... >Index: editor/libeditor/text/nsEditorEventListeners.cpp >@@ -1041,14 +1041,13 @@ nsTextEditorFocusListener::Focus(nsIDOME >+ const kIsReadonly = (flags & nsIPlaintextEditor::eEditorReadonlyMask) != 0; |const PRBool|, perhaps? I guess the k prefix belongs, here, though I always thought of that as more of a "static const" sort of prefix. r=mrbkap

Comment on attachment 198272 [details] [diff] [review] Resolves XUL textbox problems but we probably need something less hacky. Open to suggestions. + const kIsReadonly Yeah, const PRBool please (it will be an int by default).

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

although the caret does not blink, one can still think the textfield is editable, so someone could press the backspace and would be surprised to see that the browser goes back in history, see discussion in bug 332345.