30444 - html compose: Return enters two lines in a reply

Status: VERIFIED FIXED

(MailNews Core :: Composition, defect, P3)

Description

[tallison]

When I am replying to a message, if I go to the end/middle/start of a line in
the original message and hit Return to insert a new line, I get two new lines.
This only occurs when the curser is resting on an original message section of
the email.
I have the composer editing tags set to <p> for both return and enter keys.  I
can write/edit to both of these inserted lines, which implies a double <br> format.
My editing setting is for straight text for composing/sending emails

Comment 1

[tallison]

Linux 2.2.14
Mozilla M14
October Gnome

Comment 2

[lchiang]

cc: akkana

Comment 3

[Akkana Peck]

This is a feature.  It's not actually inserting two br's.  What's happening is
that the quoted text is enclosed in a <blockquote> (html compose) or a <pre>
(plaintext compose), and when you hit return, it has to split the quote block
and give you a place to type.

I'm curious what you mean by "I have the composer editing tags set to <p> for
both return and enter keys."  I'm not aware of any current way of getting
composer to insert <p> tags.

Comment 4

[lchiang]

comments received from reporter via email:

email that is received as plain text does not have this
problem.
but when I have an email that is received as HTML, then I
can get this problem.
When I hit return I get what looks like a Carriage Return
and Line Feed and another Line Feed and not a <p>, <pre>, or
<blockquote>.  I say this because I have a blinking cursor
where I can type.  But I can also move up one line and also
type.  <p> etc. don't do that to my knowledge.  I will
continue to look into it and see if I can come up with more
specifics on the details.

Comment 5

[Richard Zach]

I see the same problem.  When you put the cursor somewhere in the quoted part of
a reply message and hit Enter, you insert an extra <br>.  Closing the
<blockquote> already inserts whitespace.  

This is what the source of the replied message looks like:

<blockquote type="cite">This is a test message in HTML<br>
 This &gt;</blockquote>
<br> *** this should not be here ***
I just hit return and started typing.&nbsp; Looks like there's a blank line
above this one.<br>
<blockquote type="cite">&lt; is where I'll start typing<br>
One more line<br>
</blockquote>

To reproduce:
1. Select text message
2. Hit Reply
3. Put cursor somewhere in message
4. Hit Enter

Actual result: you get a two blank lines in between the quoted parts with the
cursor on the second line.

Expected result: one blank line with the cursor in it.  </blockquote> before,
and <blockquote> after insert extra whitespace anyway.

I have a similar problem when I reply in plain text compose. In the composer, it
looks like there are two lines before and a line after the line where the cursor
ends up, but I can only go up one line; down puts me in the quoted text, and up
two lines also puts me in the quoted text.  When I send the message, there's a
blank line before and after my reply text.  The message display of the replied
message, which has the plain text message converted to HTML (blue lines instead
of >'s to indicate the quoted part), has twice as much whitespace before the
reply text than after.

To reproduce:
1. Select message in account set to plain text compose
2. Hit Reply
3. Place the cursor somewhere in the quoted part of the text
4. Hit Enter

Actual result:  Two lines are inserted and separated from quoted text above and
below by space where you can't put the cursor.  The cursor is on the second
line.

Expected result: Either only one line is inserted, or three lines with the
cursor on the middle line.

Incidentially, it does not seem to be possible to alter the text of the quoted
message in HTML compose.  Putting the cursor there and starting to type closes
the <blockquote> and puts you outside the quotation (without a leading <br>). In
plain text compose it is possible to alter the text of the message. You want a
separate bug on that?

akkana, there's a pref for the editor that lets you choose what the Enter key
should do.  But I don't think that's in effect for HTML compose.

Comment 6

[Jean-Francois Ducarroz]

reassign to akkana

Comment 7

[Akkana Peck]

Okay, I've seen this now on html compose.  The deal is: inserting anything at
all splits the blockquote (people seem very divided on whether or not this is a
good idea, and Joe and I need to discuss this).  If what you insert is a return,
though, it gets turned into a br, and for some reason a second br is also
inserted.  We need to detect this case somehow.

Taking the bug, and cc'ing Joe since I'll probably need his help to fix it.

Comment 8

[Akkana Peck]

Oops, ended that comment prematurely 'cause I was trying to test a bugzilla
problem for terry. :-)

Anyway, Zach: thanks for the detailed test report!  I suspect that the problems
in html and plaintext compose are actually very different, but I suppose we can
try fixing one and hope it fixes the other, and if not, split off another bug.

The issue on not being able to edit the quoted text is a policy decision; I
guess we'll get lots of feedback from beta if people don't like it. :-)  I don't
think we have a bug filed on it; if you file one, file it to jfrancis, and cc me
and [e-mail] (he asked for it just the other day).  It's easy to change,
just a question of deciding that that's really the right thing.

Comment 9

[Richard Zach]

I think the problem is that Return inserts a <br> where you don't need one:
splitting the <blockquote> gives you whitespace before and after the reply text
anyway.

Filed bug 31423 on the splitting issue.

Comment 10

[Akkana Peck]

This is really a Joe issue.  I know he's working on changing the rules so that
only enter splits a blockquote; when he does that, he should also do the right
thing with the return (i.e. not insert an extra br).  Reassigning.

Comment 11

[selmer (gone)]

Mass moving to M16 to get these off the M15 radar.  Please let me know if this
is really an M15 stopper.

Comment 12

[Joe Francis]

i accept Bugzilla as my lord and savior.  

Comment 13

[Joe Francis]

fixed

Comment 14

[Sebastian Späth]

verified fixed