367223 - A plain text email containing >>>>>>>>... is display incorrectly

Status: RESOLVED WORKSFORME

(Thunderbird :: Mail Window Front End, defect)

Description

[Tony Armitstead]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Build Identifier: 1.5.0.9 (20061207)

See http://forums.mozillazine.org/viewtopic.php?t=510931&start=0&postdays=0&postorder=asc&highlight=

Basically if a plain text email contains:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Test message 

It gets displayed as a series of coloured vertical lines.

Some people use the above >>>>... sequence to seperate replies.

Reproducible: Always

Steps to Reproduce:
1. Just send yourself a plain text email containing the text
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Test message 
2. View the received message
3.
Actual Results:  
The >>>>... sequence is replaced by a seried of coloured vertical bars

Expected Results:  
I should see the >>>>>.... sequence

Comment 1

[Mike Cowperthwaite]

There is a preference to control this:
  mail.quoted_graphical
Set that to false, and for pure text/plain messages the expected quote character will be used.

For text/plain;format=flowed messages, however, the quote bar will be used regardless.  (The RFE for changing this is bug 88986.)  However, if the person writing the message typed in the '>>>>>....' separator string, and their client is properly performing f=f conversion, the separator will appear correctly.

There is a format=flowed FAQ attached to bug 168420.

Comment 2

[Tony Armitstead]

Looking at the email source I see:
Content-Type: text/plain; charset="US-ASCII"

I have changed mail.quoted_graphical to false.
I have selected View -> Message Body As -> Plain Text.

Thunderbird still shows the quote bars.

Searching the net, I have also tried changing:
mail.quoteasblock = false
mailnews.display.disable_format_flowed_support = true
mailnews.send_plaintext_flowed = false

Thunderbird still shows the quote bars.

I also tried re-starting Thunderbird and even re-booting my PC. 

Thunderbird still shows the quote bars.

Did you check that the mail.quoted_graphical = false still fixes this issue?

Comment 3

[Mike Cowperthwaite]

(In reply to comment #2)
> Did you check that the mail.quoted_graphical = false still fixes this issue?

It does behave as expected in Seamonkey.  In Thunderbird, the '>' characters are shown *but* they are preceded by the quote bar.  Unfortunately, that's one quote bar for every '>', which as you know gets unwieldy with that separator line.
See bug 249109 comment 4 for a workaround.  Maybe this should be duped to that bug.

Comment 4

[Tony Armitstead]

I put the text

blockquote[type=cite] {
         padding: 0 ! important;
         border-left: none ! important;
         border-right: none ! important;
}

into my 

C:\Documents and Settings\<me>\Application Data\Mozilla\Firefox\Profiles\thkft141.default\chrome\userContent.css

Restarted everything and ...... it made no difference. I still get the quote bars :-(

Note that there was no userContent.css prior to me copying it from the userContent-example.css file and adding in the extra text.  I presume this was the right thing to do.

Comment 5

[Mike Cowperthwaite]

Yes, that is the way (or *a* way, at least) to set up the userContent.css file.  I'm surprised you're having a problem, as this is working for me in combination with the quoted-graphical pref.  I just updated that bug with a refinement on the CSS which may make it a little better, but if you're not seeing any results from that file, there's something wrong on your side -- maybe the file's in the wrong place, or there's something wrong with its formatting.

Comment 6

[Tony Armitstead]

I used sysinternals filemon.exe and found out that thunderbird was using the following path:

C:\Documents and Settings\<me>\Application Data\Thunderbird\Profiles\kw7zxoj3.default\chrome

to look for the userContent.css file. Once I put the file in there all was well with the world (OK slight exageration :-)).

Thanks for your help.

Comment 7

[Mike Cowperthwaite]

I don't know if you've been paying attention to bug 249109, but I have been working a patch that will make the userContent hack unnecessary.