178899 - Extraneous blank quote lines appended to quoted sections of a reply (HTML compose, plain text send)

Status: NEW

(MailNews Core :: Composition, defect)

Description

[Brendan Eich [:brendan]]

I'm running the Gecko/20021031 nightly.  I reply to a message, and depending (I
believe) on whether there is trailing space on the last quoted line above my
insertion point, I now cannot hit Enter and add extra blank lines and have the
insertion point move down to follow each added newline -- the newlines append
after the insertion point, and I can't add even one visible empty line before
typing my reply text unless I click to move the insertion point down a line
after adding that line.

What's more, I then may want only one blank line after my reply text and before
the next quoted chunk of text to which I'm replying, but I often see two, and
they can't be deleted!

This seems like a recent regression.

I really need wysiwyg editing, esp. as I'm sending plaintext.

/be

Comment 1

[Mike Cowperthwaite]

Brendan Eich, is this problem still occurring for you?  I can't say I've ever 
seen this happen.

Comment 2

[Mike Cowperthwaite]

Thanks to Ben Bucksch's investigation in bug 165077 (also reported by Brendan), 
I can confirm part of this bug.  In particular, he pointed out that Brendan must 
be using the HTML mail composer and sending in plain text.

> I reply to a message, and depending (I
> believe) on whether there is trailing space on the last quoted line above my
> insertion point, I now cannot hit Enter and add extra blank lines and have the
> insertion point move down to follow each added newline -- the newlines append
> after the insertion point, and I can't add even one visible empty line before
> typing my reply text unless I click to move the insertion point down a line
> after adding that line.

I cannot reproduce this symptom.


> What's more, I then may want only one blank line after my reply text and
> before the next quoted chunk of text to which I'm replying, but I often see
> two, and they can't be deleted!

This symptom is described in detail in bug 165077 comment 11.  That bug seems to 
be primarily about the blank line entered after a quoted text being incorporated 
into the quote during the HTML->Plain conversion; I would say that this bug is 
about the extra quoted lines as seen in the (c) and (d) portions of the results, 
including in particular the lines consisting of a prefix plus two spaces:  ">  "

Reproduced with Mozilla 1.8a-0422, Win2K.  Resummarizing bug towards that 
particular symptom.  Also removing "mozilla1.3" keyword and updating OS to "All" 
(presumably Platform could be All as well).

Note that even in the plain-text composer, there are empty (quoted) lines 
appended to the quoted text at the end of the message -- bug 144998.

Comment 3

[Mike Cowperthwaite]

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

Comment 4

[Mike Cowperthwaite]

The actual results for this bug have changed slightly, but are still not 
correct; see bug 165077 comment 18.

Comment 5

[Mike Cowperthwaite]

(In reply to comment #2)
> Thanks to Ben Bucksch's investigation in bug 165077 [...]
> I can confirm part of this bug.  In particular, he pointed out that Brendan
> must be using the HTML mail composer and sending in plain text.

And (this is important) Brendan must be replying to a message that was true 
plain text (not f=f).  I say this because the quoted text for such a message is 
embedded in two tags:  <blockquote><pre>text</pre></blockquote>

There are two effects of the <pre>: the first is probably a different bug.  When 
the reply is generated, it looks like this in the source:
====
I wrote:
<blockquote>
<pre>Line 1<br>Line 2<br><br></pre>
</blockquote>
<br>
====
As viewed in the compose window, there are two apparent blank lines in the 
quote, following "Line 2".  Similar code opened in Firefox shows only one blank 
line at the end.  If you then go (in the reply window) to the end of "Line 1" 
and type <enter>, the new HTML source looks like:
====
I wrote:
<blockquote>
<pre>Line 1<br><pre>
<blockquote>
<br>
<blockquote>
<pre>Line 2<br><br></pre>
</blockquote>
<br>
====
That is, the <br> at the end of Line 1 is preserved.  As displayed in the 
compose window, there is *no* blank line shown in the quoted text at that point, 
consistent with Firefox.  It's only the end of the quote that's being shown 
incorrectly.


The second effect of the <pre> is during the HTML->plain text conversion, and is 
what this bug is about.  Each <br> within the <blockquote> results in a blank, 
quoted line.  This is arguably correct; but for those <br>'s immediately 
followed by </pre>, that blank line is superfluous -- normal rendering (without 
the bug described above) wouldn't show it.

If the message being quoted is f=f, the <pre> tag is not used (not necessary), 
and Blake's fix at bug 144998 strips out/ignores the final <br> in the plain 
text conversion.

See also bug 307112.

Comment 7

[Mike Cowperthwaite]

Reporter of the dupe notes that this problem occurs perhaps more often for Japanese users, who more frequently get text/plain mail that's not f=f.

Comment 8

[osakawebbie]

"Reporter of the dupe notes that this problem occurs perhaps more often for
Japanese users, who more frequently get text/plain mail that's not f=f."

I can confirm that, as an American living in Japan.  But I just discovered something else strange that may cause that to be more prevalent than it otherwise would be - I don't know if it's universal or just happens in Thunderbird.  If I write an email with encoding set to UTF-8 (or presumably a western set, as well), the Content-Type correctly includes "format=flowed".  But if I do the exact same thing with the encoding set to Shift-JIS (a very common Japanese charset, which I am forced to use because most cell phones still don't handle UTF-8), the f=f statement is missing.  You don't have to type any Japanese to reproduce this - I am actually using the English version of TB, and my test message was English only.  Is this a separate bug I should look for (and report if not found)?  I tried a few different search combinations but didn't find anything relevant in the titles.  But if it's true for Shift-JIS (and ISO-2022-JP, otherwise known as JIS) in other email clients, not just Thunderbird, that would explain the prevalence of non-flowed plaintext messages here, and would make one wonder if there is something about those encodings that makes f=f impossible, or a bad idea for some reason.  If that's the case, a bug report would be a waste of everyone's time.

Comment 9

[Ben Bucksch (:BenB)]

osakawebbie, in general, please do file a new bug - if nothing else, to not distract this bug. FWIW, there probably were reasons why f=f was disabled for Shift-JIS, but I don't know them. Maybe because Japanese uses space differently, and f=f uses spaces, but that's not really a good reason.