353957 - Paragraphs are reflowed unnecessarily.

Status: RESOLVED DUPLICATE of bug 86607

(Thunderbird :: Mail Window Front End, defect)

Description

[Anders Munch]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Build Identifier: version 1.5.0.7 (20060909)

When reading a text format mail or news message, paragraphs are reflowed to fit the full width of the window.  That means choosing a window width must navigate between Schylla and Charybdis: With a wide window, Thunderbird creates too long lines that are hard to read.  With a narrow window, lines are joined which weren't intended as part of the same paragraph.  In discussion threads with quotes from previous authors, it is often impossible to find a window size that is appropriate for all parts of the message.

Please allow this reflowing to be switched off (I could find no option to do that).  Or make it smarter, so that a message is only reflowed when there are lines that do not fit in the window.

If someone's going to reclassify as a feature request, I won't complain, but I really do think it's a bug, as Thunderbird misrepresents the contents of the message on screen.  The placement of line breaks is a part of the message, too.

Reproducible: Always

Comment 1

[Mike Cowperthwaite]

The preference to turn off f=f for mail you send:
  mailnews.send_plaintext_flowed
To turn it off for mail you're viewing:
  mailnews.display.disable_format_flowed_support

However, you can also decreases the logical width of your viewing window, which may solve the problem with unreadably-long lines without giving up the f=f benefits.  In your profile's chrome directory, edit (or create) userContent.css and add these lines:
  ========================
/* Set width limits on flowed text in emails */
.moz-text-flowed 
{
  max-width: 90ch !important;
}
  ========================

See bug 168420 and the faq that's attached to that bug.


> With a narrow window, lines are joined which
> weren't intended as part of the same paragraph.

Could you cite an example of this?  There are some bugs where paragraph separation can be lost when user-typed trailing spaces aren't stripped
(bug 125928 and bug 261467).  But other than that, the driving point of f=f is to make text more readable on narrow displays.

*** This bug has been marked as a duplicate of 86607 ***

Comment 2

[Anders Munch]

>> With a narrow window, lines are joined which
>> weren't intended as part of the same paragraph.
>Could you cite an example of this? 

D'oh, no I can't, I was talking out of my ass, sorry.  The problem with narrow windows is the obvious one: Either longer lines don't reflow, but wrap so one or two words go on the next line. Or the window grows a horizontal scroll bar, and the rightmost part of the text is occluded.  When a line is on the verge of wrapping, I get a spurious blank line.

> In your profile's chrome directory, edit (or create) userContent.css

Magical incantation noted, thanks. Is there some way I could have learned this without filing a dupe bug report?  Starting from the help menu I have come across http://www.mozilla.org/support/thunderbird/edit before, which tells me about where some configuration files can be found, but I never could find any information on what kind of stuff goes into these files.

>  But other than that, the driving point of f=f is to make text more readable on narrow displays.

Yet it is prone to reflow even though every single line in the message fits within the window width.  Like, for example, in news:gvzQg.117776$[e-mail]; it's immaculately legible in View Source, but the regular view reflows some of the paragraphs for no good reason.

Further, take a look at the paragraph with these three lines:

1: "Ah, cool! So it's undefined behavior in the current standard but "
2: "unspecified behavior in the draft. Makes sense! It made me nervous to "
3: "think that having mutable state in binary_op could reformat my HD :-D"

What I'm seeing at a reasonable window size is lines 1+2 reflowed, and line 3 standing on it's own.  Obviously the wrong choice in this case.  But then that's DWIM for you: inevitably, some time or another, it's going to guess wrong.  And that's why invoking a DWIM algorithm when it's not needed is just wrong.

I just tried looking at the same message after creating a userContent.css file in the appropriate place, with your incantation, and restarting TB.  It doesn't seem to work: Resizing the window, I can still get all three lines to come together on a single line on the screen.