Reply to a plaintext message in html compose. Split the quote somewhere and type something. Now use the mouse to select from the beginning of the second quoted block (right after your new text) a few lines down into the quote, and hit delete. You'll get an ubercaret every time. This is one of the most common operations in replying to mail, so it's a bad place to lose the selection.

Oops, not "every time". Dragging the selection down the left side of the quote (i.e. deleting full lines, not partial lines) seems to make it more likely.

if this is rtm, then im setting it to m19. anthonyd

Joe: I was looking at the nsHTMLEditRules::WillDeleteSelection code because of bug 54449, and I noticed that at the end, it collapses to either the start or the end node. But what if that node is gone because it's a text node and we've just deleted all the text inside it? Could that be what's happening here? I typically see it when I'm deleting collections of whole lines (which means whole text nodes, since quoted plaintext retains its line breaks and they're turned into <br> tags).

joe, how diificult will this be to fix? how risky will the fix be? how much effort will it take to get this resolved?

I checked in a workaround for 54449, which avoids this bug but has the side effect of disabling delete-to-end-of-line when on a blank line or at the end of a line (it should delete forward) by changing eNext to eNone. See the comment containing this bug id. When this bug is fixed, please also revert this workaround and set the eNone back to eNext so that delete-to-end will work fully again. Thanks! Note to PDT regarding severity: this is a very common action to do in editing email replies. I usually do this at least a couple times per message, in every reply I make. With this bug, I have to do some up/down arrowing and line-deleting in order to get the caret back where it needs to be after each time I delete part of the quoted material. It makes html mail compose a big hassle to use.

marking rtm- and setting to future

moz 0.9

moving a bunch of 0.9 bugs to 0.9.1

need to retest and reconfirm issue

Akkana, you can still get this to happen?

See my last comment: the workaround is preventing this from happening, but it's causing a different bug (marked as depending on this one).

fixed by patch in 67847.

fix checked in

Akkana, does this work for you now? thanks..

verified...doesn't happen for Akkana anymore...