Reproducibility: always Steps to reproduce: 1) Open a Mail compose window. 2) Enter a line of text: "------" 3) Open an xterm window. Type the following into the xterm: cat > /dev/null Test text. <ctrl-d> 4) Select the two lines "Test text" and the blank line following it 5) Click the middle mouse button at the beginning of the line "------" in the compose window. (note result) 6) Type something ("foo") (note result) Results: 1) After the paste, Compose window looks like this: Test text. | ------ (where "|" is the cursor.) 2) When you type the f in "foo", the cursor jumps down to the line containing "------", and the letters appear there: Test text. foo------ Expected results: After paste, cursor should be on line 3, where the text appears. This bug seems to occur whenever a middle-button paste is performed where the pasted text ends in a newline. As a result of bug 55661, all <pre>-formatted text ends in a newline, so this bug is currently more painful than one might expect.

reassign to editor frontend

-->akkana is this a dup?

I found another instance in which the same thing occurs: 1) Open a new Mail Compose window. 2) Type in the numbers 1 and 2, one on each line. (type "1<ret>2" 3) Place the cursor/caret to the left of the "2", by arrow-keying or clicking. 6) Hit <return> once, to insert a blank line. 7) Place the cursor/caret in the blank line. 8) Type a word (I typed "foo") 9) Backspace to delete it. Results: As soon as the last character in the word is deleted, the cursor hops up one line, to the right of the "1". However, when you type in a word again, the cursor hops back down, and the word appears in the blank line between "1" and "2". Expected results: Sit! Stay! Good cursor.

Dupe of bug 97207?

I don't think so. 1) Bug 97207 describes pasted text appearing in the wrong place in the window. In this bug, text appears and disappears exactly where it should, but the visible cursor "|" is displayed in the wrong place. 2) Bug 97207 specifically involves pasting text using the mouse; my second example (2001-08-28 23:06) can be produced using only the keyboard. 3) Bug 97207 can place text (and the cursor) many paragraphs away from the expected position: here, the cursor motion is always exactly one line upward. 4) But 97207 is difficult to reproduce consistently; this bug is 100% reproducible, as far as I've seen.

Edit rules -- I think Joe has a bunch of bugs like this.

Marking these all WORKSFORME sorry about lack of response but were very overloaded here. Only reopen the bug if you can reproduce with the following steps: 1) Download the latest nightly (or 0.9.6 which should be out RSN) 2) Create a new profile 3) test the bug again If it still occurs go ahead and reopen the bug. Again sorry about no response were quite overloaded here and understaffed.

Marked accidentally, reopening.

Still present build 2001-11-23-08 on linux

It occurs to me that if the selection is ever between two <br> nodes, we always want to set the interline position of the caret to bind to the second <br>. This should fix most (all?) of the "caret not on line it seems to be" bugs.

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

Note to self: need to alos fix this for basic text editor. see bug 92124.

remove the tabs from the diff :-P

Comment on attachment 59125 [details] [diff] [review] diffs for editor/libeditor/html/nsHTMLEditRules.cpp sr=kin@netscape.com Just fix the indentation.

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

fix on trunk

the blank line does indeed get selected and pasted, tested on 2003040308 trunk build on win2K