Closed
Bug 122384
Opened 23 years ago
Closed 22 years ago
Text wrapping problems in mail composition/sending
Categories
(SeaMonkey :: MailNews: Message Display, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: jhahkala, Assigned: sspitzer)
References
Details
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.7) Gecko/20011221 BuildID: 2001122106 When composing a mail, the text wraps correctly, but the sent mail is not wrapped at all. Reproducible: Always Steps to Reproduce: 1. set mail send format to convert to plain text 2. compose a mail letting the composer wrap automatically 3. send the mail (for example to you) 4. see the mail in sent folder or in your inbox Actual Results: During composition the mail looked ok and was wrapped correctly, but the actual mail sent was not wrapped, everything was in one line. Expected Results: The mail should have been sent wrapped as it was shown in the composer
Comment 1•23 years ago
|
||
Is it possible that the reporter is getting confused by format=flowed mail? I haven't heard any other reports of sent mail not being wrapped (unless this is a recent regression).
Comment 2•22 years ago
|
||
I have also been annoyed by this behavior since I began using Mozilla as my normal mail client. The behavior has changed from NN 4.7x to Mozilla. It appears to be the addition of format=flowed (as you suspected), but it is funky nonetheless. If I send myself the same message (byte for byte) using NN 4.78 and any recent Mozilla release, the Mozilla version will not wrap at the same point as the message sent via NN 4.78 (when received). The Mozilla version (as expected) contains "format=flowed" so this is not completely suprising. However, if I open up the message the Mozilla created message out of my Sent Message folder (still in Mozilla) and send that to myself, it then wraps at 80 columns, precisely like NN 4.78 did. This second generation message still has "format=flowed" so I cannot explain why it would appear differently. I even opened the files in a binary editor and cannot see anything different. If there was a way to turn off "format=flowed" that would be fine by me at least...
Comment 3•22 years ago
|
||
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417 I still have mail word-wrapping problem in RC1, as I've had ever since I started using Mozilla regularly... around 0.9.1. Here are the steps I use to reproduce the problem: Mail->Composition, Wrap plain text messages at _76_ chars Mail->Send Format, Convert to plain text 1. Hit Compose 2. Type a long paragraph, text is correctly wrapped at 76 chars 3. Hit send 4. Neither the copy mailed or the copy in the Sent folder is wrapped If, however, I hit Options->Rewrap before I send, then both copies of the mail are correctly wrapped. I encounter the same lack of wrapping in a reply as I do in a new mail, there does not seem to be a difference. The sent/Sent folder copies of the message should be wrapped the same as was displayed in the composition window.
Comment 4•22 years ago
|
||
I can confirm that bug like jhahkala@hotmail.com described with Mozilla 1.1a (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610). I also can confirm the behaviour baba@babaz.com described. Using the 'Option->Rewrap' before sending is doing nothing in my composer windows (because there it is wraped) but results in sending a wraped email, which is otherwise not wraped. thanks, Frank
Comment 5•22 years ago
|
||
Those who see this problem: Please view source of the message which has the long lines. Are the lines wrapped as the should be in the source? To turn of format flawed: http://www.hmetzger.de/etips6.html#10 pi
Summary: Text wrappin problems in mail composition/sending → Text wrapping problems in mail composition/sending
Comment 6•22 years ago
|
||
Hi, It appears to be wraped if I look at the source. What I did is: Sending a message to myself containing one very long line. I have wapping to 72 characters enabled. I did not rewrap before sending. I wrote and sent plain text. What I see if I look at the incoming mail was one long unwraped line. What I see if I look at the source (Ctrl+U) was a correctly wrapped text. I did this again but rewraped the text (Options, Rewrap in the Compose Window). What I see is a correctly wrapped text in source and in the message window as well. I use Mozilla 1.1b (2002072204) on Linux_i386. I do not have very much experience in this, therefore my guess could be completely wrong, but it looks to me like problems with incompatible line-end-characters of certain operating systems. Frank
Comment 7•22 years ago
|
||
Frank, what you see is intended. This is why I call this thing format flawed. Lines are much too long and not well readable. To solve your problem, just turn it off (see link in my previous comment). Reporter, is Frank's description, what you see? If so, this bug is INVALID. pi
Comment 8•22 years ago
|
||
Thanks pi, adding user_pref("mailnews.display.disable_format_flowed_support", true); to user.js helped. So the only problem is, that there is 1. no way to set this using the GUI, so most people will stumble over it and 2. that the default is not the disabled support. The second has maybe to be discussed, but I think the first one not, right? also thanks to all people developing mozilla (should be metioned from time to time) :-) So it is maybe time to close this bug or change it to the GUI-support-request. Frank
Comment 9•22 years ago
|
||
> 1. no way to set this using the GUI, so > most people will stumble over it and There is a bug about it already. > 2. that the default is not the disabled support. That is a (IMHO BAD) design decision. > So it is maybe time to close this bug Once we know the reporter has this same problem. pi
Comment 10•22 years ago
|
||
Marking WFM then. pi
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
Comment 11•22 years ago
|
||
*** Bug 166544 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•