93477 - Delete forward in quoted text stops at end of line

Status: VERIFIED FIXED

(MailNews Core :: Composition, defect, P3)

Description

[Paul LeBeau]

This is a strange one...

Delete forward/ahead (ie delete key) functionality is broken when editing the
*quoted portion* of a message (ie when composing a reply).

To reproduce:

- Start a reply to a message
- Position the caret at the end of a word (ie between the word and the following
space char) somewhere in the middle of a line.  Note: must be inside the quoted
block of text.
- Press and hold delete key.

Deletion will stop at the end of the line and characters on subsequent lines
will not be deleted.

If you start with the caret elsewhere - ie after the space, or in the middle of
a word, the deletion will continue past the end of the line and onto subsequent
lines (as it should).
I have experienced this with all 0.9x versions (including 0.93) - though
presumably this bug existed in prior versions also.

Couldn't find any other bug reports concerning this, but I'm surprised no-one
else has noticed it.

Comment 1

[Jean-Francois Ducarroz]

over to editor team

Comment 2

[rubydoo123]

off to tony

Comment 3

[Akkana Peck]

This is related to a bunch of other bugs regarding arrowing, deletion, and
delete-to-end-of-line in text controls.  I think it comes from the selection
getting confused about whether it's positioned before the br or after it.  (Like
so many plaintext bugs, this would probably go away if we could get the
caret-on-blank-lines bug fixed.)

Comment 4

[rubydoo123]

--> kin

Comment 5

[kinmoz]

I just attatched a patch for bug 98018 which sounds similar, but was a problem
in textareas.

Anyone know what type of mail compose we are talking about? HTML? Plaintext?

Comment 6

[Paul LeBeau]

It was plaintext.

I've just tried, and can't reproduce it on HTML mails.
From reading the history of this and similar bugs, I gather
this will not come as a surprise ;)

Comment 7

[kinmoz]

Paul, do you see a blue bar before the text you are replying to? Or do you see a
'>' character before each line?

I can't reproduce this bug using Plaintext MsgCompose and replying to either an
HTML or Plaintext email ... I can however reproduce the problem using HTML
MsgCompose and replying to either HTML or Plaintext.

I'll attatch a test case that can be opened in Composer.

I'm seeing an assertion being thrown when
nsHTMLEditRules::CheckForWhitespaceDeletion() calls wsObj.NextVisibleNode()
because it is calling GetCharAfter() with a textnode and an offset past the last
character of the text node. The error thrown by this assertion
(NS_ENSURE_SUCCESS) is propogated all the way up the stack so no deletion happens.

Here's the relavant piece of the stack:


NTDLL! 77f7629c()
nsDebug::Assertion(const char * 0x00e59584, const char * 0x00e5956c, const char
* 0x00e59540, int 599) line 290 + 13 bytes
nsDebug::WarnIfFalse(const char * 0x00e59584, const char * 0x00e5956c, const
char * 0x00e59540, int 599) line 396 + 21 bytes
nsWSRunObject::NextVisibleNode(nsIDOMNode * 0x035d1034, int 34,
nsCOMPtr<nsIDOMNode> * 0x0012e92c, int * 0x0012e8e4, short * 0x0012e8e0) line
599 + 39 bytes
nsHTMLEditRules::CheckForWhitespaceDeletion(nsCOMPtr<nsIDOMNode> * 0x0012ecd0,
int * 0x0012ecd8, int 1, int * 0x0012eda8) line 3494 + 44 bytes
nsHTMLEditRules::WillDeleteSelection(nsISelection * 0x0a83ed90, short 1, int *
0x0012ed70, int * 0x0012eda8) line 1400 + 37 bytes
nsHTMLEditRules::WillDoAction(nsHTMLEditRules * const 0x0434d194, nsISelection *
0x0a83ed90, nsRulesInfo * 0x0012ed74, int * 0x0012ed70, int * 0x0012eda8) line
466 + 31 bytes
nsPlaintextEditor::DeleteSelection(nsPlaintextEditor * const 0x04302830, short
1) line 929 + 59 bytes
nsHTMLEditorLog::DeleteSelection(nsHTMLEditorLog * const 0x04302830, short 1)
line 142 + 14 bytes

Comment 8

[kinmoz]

Attachment: Test Case 1

Comment 9

[Paul LeBeau]

Sorry.  I guess in this sense it is an HTML mail.

I thought I had everything set to plaintext, and that that
was how Moz displayed quoted sections :/

I haven't worked out how to get it to display proper
plaintext.  Please tell me how!  :/

Anyway, your test case fails (ie. exhibits this bug I mean).

Comment 10

[Joe Francis]

i believe this is fixed by my patch to 93088

Comment 11

[Joe Francis]

fix checked in on trunk

Comment 12

[rubydoo123]

using a current build from 2003040308 on win2K, exercised test case, works as
expected.