118629 - Shift-LeftArrow-Copy picks up newline (caret renders in wrong place)

Status: RESOLVED FIXED

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

Description

[kinmoz]

This bug was initially reported in bug 110186 by [e-mail] ... 
giving it, it's own bug number for tracking.

---- [e-mail] wrote:

Try this:
Go to attachment 57242 [details]
Your cursor should already be positioned right after the D like so (| = cursor):
D|
1.  So do NOT click in the box with the mouse to position the cursor.
2.  Using keyboard combo SHIFT + LEFT ARROW, hightligh the letter D.
3.  Copy the letter using keyboard combo (CTRL + V)
4.  While the letter is still highlighted, hit paste a few times using CTRL V.

You will notice that the Letter "D" is posted all on separate lines....  This 
should not be.

----

The textarea in question, contains a blank line at the end, so I'm assuming that 
the caret should initially be on the blank line below the D, between the 2 <BR> 
nodes at the very end, so shift-left will actually select "D<BR>" hence the 
newline ... which is correct, the problem seems to be that when you initialy 
scroll the textarea down, the caret is rendering right beside the 'D' character:

    D|

instead of below it:

    D
    |

like it should.

Comment 1

[Kevin Ar18]

Thanks for submitting it.  I was about to do so myself.  I just didn't feel like
taking all the time to start a new bug earlier.

Comment 2

[kinmoz]

jfrancis, is this a case where the interline position the editor sets is wrong?

Comment 3

[Joe Francis]

kin: sounds likely.  especially since this is a text widget, which doesn't have 
all the brainpower that the html editor has.  unfuturing...

Comment 4

[Joe Francis]

differentiating bug severity of my most critical bugs vai abuse of milestone field
M2: severe
M1: very severe and/or fix in hand

Comment 5

[Uri Bernstein]

Confirmed on OS X:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051001
Firefox/1.6a1 ID:2005100107

Comment 6

[Uri Bernstein]

Attachment: Simpler testcase

Easier-to-use testcase.
Notice that there is no need for the shift-left, copy, paste maneuver. Simply
typing a character will also do.

Comment 7

[Uri Bernstein]

Attachment: patch

This patch fixes this bug, and also replaces my previous fix for bug 308023.

Whenever text is inserted, either by setting the value (as in this bug), by
typing (as in bug 308023), or by pasting (with which a bug existed, but was not
reported), use the following rule:
* If the inserted text ends with a newline, set the hint to HINTRIGHT, i.e.
ensure that the caret will appear on the line following the newline.
* Otherwise, set the hint to HINTLEFT, i.e. ensure that the caret is adjacent
to the last inserted character.

My previous fix for bug 308023 worked well for the typing case, but incorrectly
interfered with the "paste" case (when the pasted text ended with a NL), and
also prevented fixing this bug (the "set value" case).

Comment 8

[Uri Bernstein]

Patch checked in by smontagu%smontagu.org, 2005-10-06 01:19.

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'm a bit scared to land a bunch of caret/selection/bidi fixes on the branch. Uri, do you have a good feeling for how things currently are on the trunk? Are we in a good state?

Comment 10

[Uri Bernstein]

(In reply to comment #9)
> I'm a bit scared to land a bunch of caret/selection/bidi fixes on the branch.
> Uri, do you have a good feeling for how things currently are on the trunk? Are
> we in a good state?

As far as I know, there are currently no regressions on the trunk resulting from caret fixes. That is, the trunk is in an absolutely-better state (caret-wise) than the 1.8 branch.

Comment 11

[Uri Bernstein]

Checked in to 1.8.1 branch:
Checking in mozilla/editor/libeditor/text/nsTextEditRules.cpp;
/cvsroot/mozilla/editor/libeditor/text/nsTextEditRules.cpp,v  <--  nsTextEditRules.cpp
new revision: 1.195.4.1; previous revision: 1.195
done