i noticed that tabbing goes to readonly fields --shouldn't those be skipped? 1. go to a dialog that has readonly fields, such as the Cookie Manager dialog or the download progress dialog. 2. start tabbing through the widgets...you'll notice "dead spots" where you don't see the focus ring [and allow no user action] which correspond to being in a readonly field. each "dead spot" would correspond to each readonly field in the dialog.

I think this needs to work like this, you can still select and copy text from a readonly field. The real bug is that we don't show a blinking insertion point in readonly textfields (even though one does exist) as Windows does. That's probably easy to fix, cc'ing simon.

We should not show a blinking caret in readonly fields, since the blinking caret indicates that you can type there. We might want to show a non-blinking greyed- out caret.

Why does it necessary indicate that you can type? I think the gray background makes it clear you can't. But anyways, I was just pointing out Windows behavior. I think a non-blinking caret would be odd.

Sounds like we'll need platform specific behavior. on windows it should blink (as blake says), on macos i guess it probably shouldn't.

Changing summary, because I don't want someone skipping these fields in the tab order.

aaronl, considering your 2001-11-05 09:33 comments, should bug 83566 be wontfix'd?

I really don't consider a readonly field a deadspot at all. What I meant by deadspots are things where the focus can't be made visible, and it's not an interactive widget. For example, when the focus was going to "invisible" widgets, or to the find dialog's window, you couldn't tell where you were. There was no reason to be there, either. Dead spots are when you're tabbign along and suddenly -- where are you?

thanks for the clarification! makes more sense to me now.

this seems like it should go over to editor.. i'm not really familiar with our caret code. please assign back if i'm wrong.

Marking nsbeta1-.

-

Oops, I added the nsbeta nomination here by accident. I got this confused with bug 113602. Kevin, you were correct in removing it.

Dup of bug 89689?

I just put a fix for this in 89689, at least on web pages. Didn't test XUL

I definitely think this is a dup of bug 89689. *** This bug has been marked as a duplicate of 89689 ***

verified.