Closed Bug 97259 Opened 23 years ago Closed 23 years ago

Visible caret position incorrect after pasting blank lines

Categories

(MailNews Core :: Composition, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.7

People

(Reporter: goodmanj, Assigned: mozeditor)

References

Details

(Whiteboard: EDITORBASE; 0.5 days; fixinhand; need r=, sr=)

Attachments

(1 file)

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
Assignee: ducarroz → syd
QA Contact: sheelar → sujay
-->akkana
is this a dup?
Assignee: syd → akkana
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.
Summary: Visible cursor position incorrect after pasting blank lines → Visible caret position incorrect after pasting blank lines
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.
Assignee: akkana → jfrancis
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.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Marked accidentally, reopening.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Still present build 2001-11-23-08 on linux
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Status: NEW → ASSIGNED
Whiteboard: EDITORBASE; 0.5 days; fixinhand; need r=, sr=
Target Milestone: --- → mozilla0.9.7
*** 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.
Attachment #59125 - Flags: superreview+
*** Bug 107897 has been marked as a duplicate of this bug. ***
fix on trunk
Status: ASSIGNED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
the blank line does indeed get selected and pasted, tested on 2003040308 trunk
build on win2K
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: