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
reassign to cmanske
Assignee: beppe → cmanske
I don't do carets ;-) Both Simon and Tony are busy. Any ideas who could do this?
Assignee: cmanske → beppe
load balancing some bugs -- assigning to sfraser and setting to moz0.9.1
Assignee: beppe → sfraser
Priority: -- → P3
Target Milestone: --- → mozilla0.9.1
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.
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!
Summary: Selecting text in table cell and moving across cells shifts cursor to the other cell → Selecting text in table cell and moving across cells shifts caret to the other cell
This is blake's bug.
Assignee: sfraser → blakeross
going to unset target milestone. blake, set to something reasoable when you get a chance.
Target Milestone: mozilla0.9.1 → ---
This is fixed now that the caret is off (and jfrancis' checkin may have fixed it anyways).
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Verified on 8-28 build
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.