116688 - mail is always wrapped when reading plaintext-mails, regardless of settings in global config

Status: NEW

(MailNews Core :: Backend, defect)

Description

[Juri Haberland]

Mails with long lines are always wrapped at window border regardless of the
setting  "Wrap text to fit window width" in the global config dialog (Edit ->
Preferences ->   Mail & Newsgroups -> Message Display). This happens in the
preview windows and also if the message is opened in a seperate window. The
mails in question are all plaintext mails.

Comment 1

[Juri Haberland]

I observed this behaviour also on Linux with an older release (0.9.6?).

Comment 2

[Boris 'pi' Piwinger]

I see the problem in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a)
Gecko/20020610.

pi

Comment 3

[Koike Kazuhiko]

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

Comment 4

[Koike Kazuhiko]

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

Comment 5

[John Levon]

dupe of bug 155219 it seems (which has patch). Yes ?

Comment 6

[Alexander Becker]

I think bug 155219 is about wrapping at mail writing time.
The problem i mentined is about reading of plaintext-mails.

Comment 7

[Andy Behrens]

Bug still present in Mozilla 1.2.1 on Linux (Redhat-8.1)

I'd like this to be considered as a higher priority than "minor".  Some of our
users receive e-mailed reports which are plain-text, 200 chars wide, with data
in columns.  If users have a high-resolution display, they can (as a
work-around) drop the font size down until the entire width is visible on the
screen.  But users with  lower-resolution displays don't have that ability. 
They would like to use horizontal scrolling to see the columns they are
interested in.  Although there are work-arounds, they are inconvenient and clumsy.

Comment 8

[Alexander Becker]

i just tested it out on the new Mozilla 1.4final/Win.
The bug is still present in this latest release.
It is very annoying to view plaintext-logfile-emails containing long lines with
linewrapping...
i hope someone will fix this (i think very small) problem.

I hope in upcoming thunderbird this bug will not be implemented :-)

Comment 9

[Mike Cowperthwaite]

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

Comment 10

[Mike Cowperthwaite]

Note that bug 155219, mentioned above in comment 5 & 6, was marked invalid.

As noted in the dupe, I am unable to see any effect on wrapping (as opposed to 
scrollbar) in either message windows or compose windows, with any of these 
preferences:
 mail.compose.wrap_to_window_length    default: false
 mail.wrap_long_lines                  default: true  <- in Preferences UI
 news.wrap_long_lines                  default: true

However,   view_source.wrap_long_lines   does work as expected.

Scrollbars do appear in the compose window if a quoted line is wider than the 
window; same for the message display window if the quoted lines are not encoded 
with format=flowed

Comment 11

[Mike Cowperthwaite]

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

Comment 12

[Mike Cowperthwaite]

I did a little digging into the source, and found the reason for this, 
currently at:
  http://lxr.mozilla.org/mailnews/source/mailnews/mime/src/mimetpla.cpp#206
The test of |obj->options->wrap_long_lines_p| is where the pref's value is 
being checked.  Altho the <div> does in fact get the 'wrap=false' when this 
pref is turned off, the text of the message is contained within a nested <pre> block -- and as seen at the end, that <pre> block has a 'wrap' attribute, which (by a rule in quirk.css) gets |white-space: -moz-pre-wrap| -- so the text does get wrapped after all.

The code is just wrong -- that |wrap| attribute on the <pre> should not be included if the pref is off, and the |wrap| attribute on the containing <div> should simply be removed, as it adds nothing either way.  (I think, but am not sure, that the second addition of |<pre wrap>| (the |plainHTML| case) should 
not have the |wrap| attribute either.)

However, a workaround is possible.  Add this to userContent.css:
  div[wrap=false] > pre[wrap] { white-space: pre !important; }

Incidentally, this works for news as well as mail, and the pref 
|news.wrap_long_lines| has no references to it other than those setting the value in the file -- it's nothing but cruft.

Comment 13

[Mike Cowperthwaite]

(In reply to comment #10)
> As noted in the dupe, I am unable to see any effect on wrapping (as opposed 
> to scrollbar) in either message windows or compose windows, with any of these 
> preferences:
>  mail.compose.wrap_to_window_length    default: false

I'm not sure what went wrong with my testing here.  The pref name quoted is incorrect; it should be   mail.compose.wrap_to_window_width   -- and that does have an effect on wrapping during composition, similar to setting the wrap column to 0; but see bug 233705.


> However,   view_source.wrap_long_lines   does work as expected.

Not in Thunderbird, however: bug 312478.

Comment 14

[Kyle K.]

This bug hasn't seen any activity for over 4 years now.  Is this on anyone's radar at all?  I just got bit by it and am frustrated that I have to use the userContent.css "all or nothing" approach.

Please provide a simple "wrap" toggle button when viewing email.

Comment 15

[Mike Cowperthwaite]

(In reply to comment #14)
> This bug hasn't seen any activity for over 4 years now.  Is this on anyone's
> radar at all?  I just got bit by it and am frustrated that I have to use the
> userContent.css "all or nothing" approach.
> 
> Please provide a simple "wrap" toggle button when viewing email.

This almost certainly not on anyone's radar.

Anyway, the all-or-nothing result is exactly what this bug is calling for -- the pref doesn't work at all, and it should.  A toggle button is a different issue; it would be an RFE, and unlikely to be implemented except as an extension.  Such an extension would probably work either with the bug fixed or with the CSS.

Comment 16

[Andy Behrens]

(In reply to comment #14)
> Please provide a simple "wrap" toggle button when viewing email.

Actually, there was a check box to do this back when this bug report was created --FF 1.5 had it. It was taken out of the Preferences menu at some point when the user interface was simplified.

Whether check box or config setting, it should still work.

Comment 17

[chrizilla]

clarifying bug title based on comment #6