29680 - format=flowed mail doesn't rewrap on linux

Status: VERIFIED FIXED

(MailNews Core :: Backend, defect, P3)

Description

[fenella]

Win32 (2000-02-29-09 M15)
Steps
1. Launch Messenger using -mail option
2. Using the Plain text editor, reate a message that contains lines with more 
than 72 chars and without line break.
3. Read the message

Actual result: The text wraps to fit the size of the window, which may less than 
72 chars or llarger than 72 chars.

Expected result: Like Nova, it should wrap with 72 chars column width

This does not occur on Linux.

Will test Mac

Comment 1

[lchiang]

may be related to http://bugzilla.mozilla.org/show_bug.cgi?id=24930.

Comment 2

[fenella]

Mac (2000-02-29-08 M15)
This problem does not occur on Mac. 
I forgot to mention that I have tried to turn-on and turn-off the check-box
"Wrap plain text message to fit window width" in the Prefernce|Mail and
Newsgroup | Messages. 
The result is the same.
Win32: Plain text wraps message to fit window width
Linux and Mac: wraps with 72 chars column width.

Comment 3

[Phil Peterson]

This is not a bug. Messages composed by mozilla use the "format=flowed"
convention for soft-wrapping body text. If we sent a message without
"format=flowed" (and I'm not sure how to do that, offhand), then I'd expect the
body text to be hard-wrapped (like 4.x did).

Comment 4

[Phil Peterson]

Oops. didn't notice that this had been reassigned to akkana. Akkana, sorry for
resolving it on you. Let me know if you disagree :-)

Comment 5

[Akkana Peck]

I was under the impression that format=flowed was optional, since not all remote
mail clients will deal with unwrapped text.

The odd thing is that I see plaintext messages wrapped correctly, Fenella sees
them not wrapped at all, and we're not sure what the difference is in our prefs.

Daniel, what's the current status of format=flowed, and why is it that Fenella
sees her messages flowed while I see mine wrapped?  Is there a hidden pref?

Comment 6

[Akkana Peck]

Okay, I'm going to reopen this at least until I find out the status of the pref,
and why Fenella and I see different behavior, and how I can tell other people
how to get one behavior vs. the other if they don't like the default.

Comment 7

[Daniel Bratell]

As Phil said, if the message is format=flowed (look at the content-type 
header), it behaves a lot like HTML mail. Format=flowed mails don't know the 
concept of line breaks because of too long lines but leaves that to the layout 
engine to deal with. 

Phil, to turn off format=flowed, set the "mailnews.send_plaintext_flowed" pref 
to false.

Comment 8

[Daniel Bratell]

I _think_ format=flowed works now. It was broken some time ago but that should 
be fixed now, unless the patches that fixed it haven't got checked in yet.

I will try to check it later if I can get a clean tree, without my local 
chenges, to build.

Comment 9

[Akkana Peck]

We looked at Fenella's prefs and searched for "flow", and didn't find any
matches.  I looked at my prefs.js, and didn't find any matches there either.

So somehow Fenella and I are defaulting to different values of this pref,
without either of us specifying it explicitly in prefs.js.

Is there somewhere other than prefs.js that this could be being set?

Comment 10

[Daniel Bratell]

That reminds me of something. When format=flowed was introduced, the change to 
the default pref file were never checked in. Since the code was written to 
work without it, I never cared to complain, but it's still in my local tree. If 
you want to help me, the patch is below.

Index: mailnews.js
===================================================================
RCS file: /cvsroot/mozilla/modules/libpref/src/init/mailnews.js,v
retrieving revision 3.44
diff -r3.44 mailnews.js
136a137
> pref("mail.send_plaintext_flowed",          true);  // RFC 2646

Comment 11

[Akkana Peck]

Okay, here's the scoop.
I tried adding 
user_pref("mail.send_plaintext_flowed", true);
to my prefs and sent a message; when it arrived on the other end, it did have
Content-Type: text/plain; charset=us-ascii; format=flowed

with line breaks set at the correct places (where they were shown in the
plaintext compose window when I sent the message), and the message looks fine
(like an ordinary plaintext message) in 4.7 and in a line-mode mailer on Unix.

The difference is in how mozilla mail shows it.
On Linux: it shows it just like any other plaintext message, or like 4.7 or a
line mode mailer would show it.  Resizing the window smaller than the line
length gives a horizontal scrollbar.
On NT: it shows what Fenella saw: resizing the window causes the text to rewrap
to the new window size.

Replying to the message in a plaintext compose window on either platform, or in
html compose on NT, looks like a reply to an ordinary unflowed plaintext
message, with hard wraps, and a horizontal scrollbar if I resize the window too
small.  (Is this right for format=flowed, or should it be wrapping?  If it's
wrong, file another bug, probably to me, since it likely involves tweaking the
editor's InsertAsQuotation methods.)

Why are Linux and NT different in the mail window?  That's the remaining issue
-- the windows mailer window reflows the text when you resize the mail window,
the linux mailer window doesn't.  That seems like a weird mail pp bug, so I'm
sending it back to Phil for triage, and resummarizing to reflect that this is
the bug.

Also, Phil, shouldn't we check in Daniel's change to set the default value of
the pref?  It's apparently getting set to something random now (false for me,
true for Fenella).  This isn't a beta1 blocker, but it might be worth
considering release noting it.

Comment 12

[Phil Peterson]

I grepped the code for places reading this pref. I found three occurrences: two
checked the nsresult from GetBoolPref and the third didn't, but initialized the
local PRBool to true. What this tells me is that Daniel's patch would be ok to
have sometime, but is likely not going to fix this problem for us. Sounds like
that agrees with akkana's empirical testing.

If I'd found a lurking Uninitialized Memory Read (i.e. not initializing the
local variable *and* ignoring the return value from GetBoolPref) then I would
have pressed to fix that for beta1.

So, if the bug is just that format=flowed messages don't rewrap on Linux, for
reasons as yet unknown, that should go to Daniel. cc'ing rhp just for fun.

Comment 13

[Ben Bucksch (:BenB)]

[Flowed quotes]
> If it's wrong, file another bug

Filed bug #29699.

Comment 14

[Daniel Bratell]

So what's the status of this bug? I don't have any linux machine to test on and 
can't reproduce it in windows and generally don't know what's wrong. It 
shouldn't be assigned to me anyway I think since format=flowed has nothing to 
do with what happens in a composer window. It's first when "send" is issued 
that the processing is done.

Reassigning to Akkana. 

Comment 15

[Akkana Peck]

The problem at this point isn't with the compose windows, it's with the message
pane and why it handles flowed messages differently on different platforms, and
with getting the default value for the pref checked in (and perhaps some way to
change it in the UI?)

I don't know anything about message pane styles; assigning back to Phil for
reassignment who whoever owns display in the message pane.  I'll be glad to help
whoever gets it if they need Linux platform help (I nearly always have a current
build where I can test things).

Comment 16

[Phil Peterson]

Scott, can you take a look at this since Daniel doesn't have a Linux box? Thanks.

Comment 17

[Phil Peterson]

Oh, wait, this is with the body, not the envelope. Sorry Scott. I meant Rich :-)

Comment 18

[rhp (gone)]

Ok, I think that we are seeing the same problem as 31036 which I have fixed and
will totally hork up plain text message wrapping.

- rhp


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

Comment 19

[fenella]

Mark it verified/dup.

Comment 20

[fenella]

Per Akkana, this bug should not be a dup of 31036. 
I re-tested this bug using the following builds. The problem is fixed.
Linux (2000-03-10-13-M15) and  Mac(2000-03-10-13-M15) and
Win32 ((2000-03-10-12-M15)

Comment 21

[fenella]

Mark it Resolved/Fixed

Comment 22

[fenella]

Mark it verified.