200854 - No space after quote ">" character when converting HTML to plain text

Status: VERIFIED FIXED

(MailNews Core :: Composition, defect)

Description

[Louis Kruger]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030405
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030405

I'm reporting this bug because a friend of mine who I sent mail to complained
about it.  Its harder to read without the space after the ">".


Reproducible: Always

Steps to Reproduce:
1. Reply to a message using HTML composer with some quoted text
2. After clicking send, the dialog pops up with the option to convert to plain
text or send in HTML.
3. Chose "Send in Plain Text Only"

(note I can reproduce the bug even if without the dialog box, if Mozilla knows
to send to that recipient in plain text)
Actual Results:  
Message is formatted like this:

Someone wrote:
>blah blah blah

Expected Results:  
Message is formatted like this:

Someone wrote:
> blah blah blah

Note the extra space after the quote character.  Using the plain text composer
does put the space there, as do most other mail programs.

Comment 1

[Mike Cowperthwaite]

I've just tried to reproduce this problem (under Win2K) using 1.6 and 1.7b, and 
could not.  I get the same, correct, behavior whether the original mail was HTML 
or plain, whether f=f is turned on or off.

Louis Kruger, are you still experiencing this problem?

Comment 2

[Mike Cowperthwaite]

OK, I've found the case where this happens (see bug 165077).  The mail being 
replied to needs to have been text/plain and *not* format=flowed.

Reproduced with
  Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040406

Comment 3

[Ben Bucksch (:BenB)]

I thought this was just a simple ommision of the space, but there is code to
output that space. I don't see why it doesn't work:

content/base/src/nsPlainTextSerializer.cpp::OutputQuotesAndIndent()

  // Put the mail quote "> " chars in, if appropriate:
  if (mCiteQuoteLevel > 0) {
    nsAutoString quotes;
    for(int i=0; i < mCiteQuoteLevel; i++) {
      quotes.Append(PRUnichar('>'));
    }
    if (!mCurrentLine.IsEmpty()) {
      /* Better don't output a space here, if the line is empty,
         in case a recieving f=f-aware UA thinks, this were a flowed line,
         which it isn't - it's just empty.
         (Flowed lines may be joined with the following one,
         so the empty line may be lost completely.) */
      quotes.Append(PRUnichar(' '));
    }

Comment 4

[Mike Cowperthwaite]

See bug 165077 comment 18 -- this symptom is no longer occurring in trunk 
builds, probably due to the patch for bug 144998.  (Blake, do you think that's 
likely?)

Comment 5

[Blake Kaplan (:mrbkap) (inactive)]

Actually, I think I remember fixing this bug when I fixed bug 144998. See, in
particular bug 144998 comment 88, the last part of my response seems to be
devoted to just this bug.

For the record, the problem, as I remember it, was that we were calling
OutputQuotesAndIndent without using mCurrentLine. This was confusing the
function into thinking that we were outputting an empty line, causing it to
output ">" instead of "> " (to protect f=f from thinking that this was a wrapped
line). I fixed things so that we filled mCurrentLine, causing
OutputQuotesAndIndent to do the right thing.

Marking as FIXED.

Comment 6

[Blake Kaplan (:mrbkap) (inactive)]

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