41077 - Caret hidden by selection

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect, P3)

Description

[[e-mail]]

When text is selected the caret disappears.
As a side effect, there is no way to tell if the end of a line is selected,
without moving the caret.
I can't tell if the bug has something to do with the colour used by a selection,
#7F7F7F looks rather like #808080 on my machine.

Comment 1

[Blake Ross]

there's tons and tons and tons of caret/focus issues but for some reason I can't 
find this one.  I think it's one of saari's or mjudge's...

Comment 2

[rubydoo123]

yes, there are lots of caret issues, assigning to mjudge and setting to m17

Comment 3

[Guillaume Filion]

Attachment: HTML generated by Nestcape Navigator 4.7.3 when reading the page.

Comment 4

[Guillaume Filion]

Sorry, I sent the attachment to the wrong bug id. Please delete it.

Comment 5

[mjudge]

let me talk to simon about this see if he has opinions.

Comment 6

[Simon Fraser [no longer active]]

I don't understand this bug. if you have a collapsed selection, you see the 
caret. If the selection is non-collapsed, you see the selection as a coloured 
area. You should never see both.

Comment 7

[[e-mail]]

You always see the caret in standard Windows controls so you can see whether it 
is at the beginning or the end of the selection. N.B. If your selection 
background colour is dark gray it makes it harder to see the caret at the 
beginning of the selection.

Comment 8

[Simon Fraser [no longer active]]

Oh, I see. I don't see why you need to see it, though, since if you type or do 
anything else, the entire selection is replaced. I think Windows has poor UI 
here.

Comment 9

[rubydoo123]

setting to nsbeta3+

Comment 10

[Simon Fraser [no longer active]]

No way. This bug is a wontfix.

Comment 11

[sujay]

verified in 7/27 build.

Comment 12

[rubydoo123]

not so fast -- this is a regression on windows and that needs to be addressed. 
Just because the mac does it differently does not mean the window functionality 
is wrong. Windows users do see the caret after selection.

Comment 13

[rubydoo123]

how do we address this issue with windows users -- considering this will be, 
maybe, the only windows app that behaves like this.

Comment 14

[rubydoo123]

well, I apologize, I just did some testing on win and this is not the case 
across all apps, so I am remarking this wontfix and remarking it verified

Comment 15

[rubydoo123]

remarking it verified

Comment 16

[Blake Ross]

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

Comment 17

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Well, I think this IS a useful feature, but I will not battle for it. And so far 
I have seen only a couple of Windows programs that hide the caret... Making 
Mozilla the oddball. NN 4.x shows it as well.

About the useful case... Suppose you have some text, and a part of it is 
selected (between _'s):

Some t_ex_t

If you press the arrow left key, where is your caret going to be? Answer: you do 
not know without trying. On Windows you would normally see the caret at either 
_, so you will know where your caret will be if you press arrow keys.

Comment 18

[Peter Trudelle]

FWIW, Windows Interface Guidelines don't seem to have anything to say about 
this.  The only justification I could find for it was that insertion points 
indicate the input focus "in all cases", however I don't see one in any of 
their illustrations of selected text.  It does also seem to reliably indicate 
the active end of the selection, although I don't see any mention of that.  
In answer to Heikki's question, I think our current convention of treating the 
selection as one large insertion point (ala Mac) is much more useful, since you 
can get to either side of it with a single keystroke. Windows users will this 
as a defect though.

Comment 19

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Ok, I can easily accept this for single line text fields. But multiline is not 
that clear:

Some t_ex_t
Other prose

If I press arrow down, I seem to get to the end of the selection, and arrow up 
will get me to the beginning. I guess this is the only sensible thing to do 
provided the caret is not visible.

While testing this, I noticed something that definitely seems to be a bug: in 
the multiline case, after the second arrow down you will move to the line below, 
but it appears you will move into a wrong place. It looks like the caret moves 
one line down AND one character right. Also you do not need a selection for 
this, it looks like every second position on the upper line has this feature. If 
you have selection it happens regardless of position. Is there a bug on this 
already?

Comment 20

[Simon Fraser [no longer active]]

Probably not; look at mjudge's bugs, and file a new one on him if not.

Comment 21

[Blake Ross]

Beth, out of curiousity, what Windows app did you try that didn't show the 
cursor?  Every Windows app I've used has shown it, and it just looks weird 
without it.

Comment 22

[Matthew T (active 1999-2002)]

Windows apps which use the OS's text control (e.g. Notepad, Excel, and Internet 
Explorer's chrome) show the caret when a selection is made. Apps which use 
their own controls (e.g. Word, Wordpad, and Internet Explorer's HTML form 
controls) typically do not. So I think we can pretty much do what we like here 
on Windows. Showing the caret could be slightly misleading for some users, in 
suggesting that a selection will not be cleared when the user starts typing. So 
we should only show the caret if it provides enough useful information about 
what other (non-typing) key keystrokes will do, to outweigh that confusion.

In apps which do show the caret with a selection, the Left and Right keys clear 
the selection and move the caret to the left/right of its previous position. In 
apps which do not (and on Mac OS), the Left and Right keys clear the selection 
and move the caret to the beginning/end of where the selection was. Result: No 
gain from showing the caret. Behavior is predictable whether or not it is shown.

Now to the Up and Down keys. In apps where the caret is visible with a 
selection, Up and Down move clear the selection and move the caret to the 
character boundary above/below the caret's previous position. In apps where the 
caret is not visible with a selection, there doesn't seem to be consistent 
behavior -- Word, Wordpad, and Internet Explorer behave in three different 
ways. Result: Gain from showing the caret, since you remove yourself from the 
confusion present amongst the apps which do not show it. (On Mac OS, IIRC Up 
and Down clear the selection and move the caret to the beginning/end of where 
the selection was.)

Then there's Shift+Left/Right/Up/Down. Whether or not the caret is shown here 
has no effect on the behavior, which is to extend the last-specified end of the 
selection by one row/column in the direction of the arrow key. In this case 
there is a clear gain from showing the caret, so that you know which end of the 
selection is going to be shifted.

So, on balance I think the caret should be shown when there is a selection in 
either Windows or X. It should not be shown on Mac OS, but then Mac OS should 
have different behavior for the Up and Down keys in a selection (so knowing 
which end of the selection is the active one isn't nearly as important).

Comment 23

[Blake Ross]

Taking...

Comment 24

[Blake Ross]

Attachment: [patch] show caret in selection on Windows

Comment 25

[Simon Fraser [no longer active]]

sr=sfraser on the patch (I can, I own the caret).
Just one thing, though -- check with Aaron Lev. that this does not mess up his 
showing the caret in the browser (which he needs for accessibility).

Comment 26

[Aaron Leventhal]

Simon, it should be okay. I'll be doing more testing with "show caret in
browser" later on. The sooner this is in to test with my code the better.

Comment 27

[Blake Ross]

Fix checked in (r=hurricane).

Comment 28

[sujay]

verified in 1/23 build.