68843 - Selecting text in table cell and moving across cells shifts caret to the other cell

Status: VERIFIED FIXED

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

Description

[shrirang khanzode]

I see this on the windows trunk build 0214

Steps:
1 Launch composer and add a table of 2x2
2 Type something in first and its adjacent cell (first row)
3 Now keep the caret at the last character of the second cell and highlight the   
  cell contents with mouse and cross the cell boundary.

Actual result : Observe that the caret is now actually blinking in the first 
cell 

not sure if this is the expected output but 4.x behaves differently

Comment 1

[Kathleen :Brade]

reassign to cmanske

Comment 2

[Charles Manske]

I don't do carets ;-)
Both Simon and Tony are busy. Any ideas who could do this?

Comment 3

[rubydoo123]

load balancing some bugs -- assigning to sfraser and setting to moz0.9.1

Comment 4

[kinmoz]

I think the bug here is that the caret shouldn't be visible when there is a 
non-collapsed selection ... the fact that the focus node of the selection snaps 
to the end of the text in the first cell, after you've crossed the cell boundary 
is irrelevant.

Comment 5

[Charles Manske]

I agree and filed bug 64643 on the issue. Blake Ross owns that bug and claimed
he turned on the caret as a fix for bug 41077. It seems textfields (at least
in Windows) do show a blinking caret at the end of the selection highlighting,
but you usually don't see that behavior in word processors such as MS Word.
So we really need to decide if we want a caret or not!

Comment 6

[Simon Fraser [no longer active]]

This is blake's bug.

Comment 7

[chris hofmann]

going to unset target milestone.  blake, set to something reasoable 
when you get a chance.

Comment 8

[Blake Ross]

This is fixed now that the caret is off (and jfrancis' checkin may have fixed it 
anyways).

Comment 9

[James Baxter]

Verified on 8-28 build