From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.0 i686; en-US; m18) Gecko/20010131 BuildID: 2001013121 When I select a text in a message being composed, and delete it, the cursor does not stay where the text has been deleted, but goes at the beginning of the message. Reproducible: Always Steps to Reproduce: Create a message, type some text, select a word in the middle of the text, delete it. Actual Results: The cursor moves to the beginning of the message. Expected Results: The cursor should stay where the text has been deleted.

Reassign to editor team

I am pretty sure that this bug is a dup of bug 62477.

assigning over to anthonyd

actually, this should go to simon -- simon tracing the reference to the dup in this bug -- it led me to 53610 -- which is one of your bugs

No, it's unrelated to 53610. This bug should be joe's

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

This bug is reproducable with 2001020604/Win98.

I only see this after selecting text at the end of a line (bug 53610).

Nominating for nsbeta1. This will be frustrating the end user. Selecting a bunch of text and deleting is a common operation.

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

we are having trouble reproducing this bug in a current build, moving over to 9.2 and asking reporter to please retest on a current build.

I can still reproduce caret jumping to top of message when deleting on win98, 2001-05-16-05-trunk steps to reproduce: 1. compose new (plaintext) mail 2. type a word on a line, copy and duplicate line n times 3. go to end of message, select backwards any number of characters 4. hit del -> text deleted, caret jumps to beginning of message Another version: 1 & 2 as previous 3. go to beginning of any line, shift-up to select a row (or shift-up-left if bug 80048 applies) 4. hit del 5. repeat steps 3 & 4 once -> caret jumps to beginning of message I cannot reproduce *exactly* the original report though, "select a word in the middle of the text, delete it" works okay.

I ran into this about 10 times while I was typing my answer sheet for the CS70 test in Mozilla Composer: 1. Select some text at the end of any line, going several pixels past the last character on the line. 2. Hit the delete key. Result: Insertion point moves to the beginning of the document. User is momentarily disoriented (thinks he accidentally deleted a large portion of the document), and after running into this bug several times, very annoyed. Btw, I think bug 77440 is a dup of this bug.

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

we really need to fix this for rtm; probably release note it for beta

attach patch fixes prob and also removes workaround for 54449, which is no longer needed.

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

+ if (leftParent == rightParent) return NS_OK; I forget if this breaks the linux compiler; might prefer: + if (leftParent.get() == rightParent.get()) return NS_OK; r/sr=sfraser

per asa in a mailnote: 67847 Deleting selected text in message compose makes caret go to beginning of message approval noted in the bug. and I have pinged him to please make entry in this bug

I'm a dork. sorry. Thanks for all the great editor fixes. I used composer to do my entire focal self eval and had absolutely no problems :) a= asa@mozilla.org for checkin to the trunk. (on behalf of drivers)

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

fix checked in

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

This bug is reproducable with 2001061804/Win2k in the following steps. (1) Hit reply button. (2) Select the half of the quotation by Shift+Up arrow and hit Delete.

the only wat I could reproduce this one is to delete the quoted text and delete all the way to the very end, something about going to the end triggered the caret to jump to the top of the note. If I partially selected the quoted text, the caret stayed put.

using 2001061905 I still can produce this bug when composing a reply if I mark and delete the lower part of a quotation (format "Preformat") and something below that quotation (format "Body Text"). The caret does not jump if all the quotation is selected or if only teh upper part of the quotation is selected or if nothing below the quotation is selected.

fix checked in

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

The cared is placed at two lines below the quotation after deleting. And the part of the message text disappears. It's not repainted correctly. Reopening again.

Is this html mail? The "two lines" would be correct; there is a vertical margin around the mail cite. The other problems should be filed as new bugs against layout.

marking verified...please file the other problems as layout bugs...thanks.

Plain text mail. Did the spec change recently? I filed a bug 86969 for repainting problem.

Actually, I see a vertical margin in plaintext mail too. You can tell this because you cannot up-arrow to the "blank" line. I don't know why we have what margins we have. That should be determined by the user agent css, I suppose.

You can see a blank line if you save the message as draft.

I have no problems with redrawing or blank lines that can't be up-arrowed to, and confirm the caret positioning issue solved (build 2001062004 on W2K). The only issue that remains is that blank lines are added before and after quoted material when saving/sending the message. Is this a bug or a feature?

Bug 67391 for blank lines before and after the quotation. But "a vertical margin" should also be removed.