785706 - (Bogus_EOL_>_char_998) Message composition breaks at char 998 - bogus EOL added - breaks word in two.

Status: RESOLVED DUPLICATE of bug 653342

(Thunderbird :: Message Compose Window, defect)

Description

[u328884]

Attachment: xxx xxxxxx!.eml

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20100101 Firefox/14.0.1
Build ID: 20120713134347

Steps to reproduce:

Compose a message with a paragraph longer than 998 chars.


Actual results:

The 4-char word ('zzzz') at char # 996 is broken into pieces: 'zz'+'\n'+'zz'.


Expected results:

The '\n' is bogus. It should not be there.

Comment 1

[Ludovic Hirlimann [:Usul]]

Mark does this happens also on http://www-archive.mozilla.org/editor/midasdemo/ ?

Comment 2

[u328884]

Ludovic... I don't know anything about midasdemo. I'm just a simple Tbird user who knows enough C syntax to be dangerous. I attached xxx xxxxxx!.eml so you can play with it. Cut the paragraph out and try it.

Comment 3

[WADA:World Anti-bad-Duping Agency]

A known phenomenon which is seen in bug 653342 comment #14. If the forced wrapping at 998bytes happens at mid of 3bytes code or mid 3 bytes escape sequence, Bug 355209 occurs. 

Text mode mail composition? Or HTML mode mail composition(text/plain mail even though composed as HTML by you)?
Mail is format=flowed mail.
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Why no wrapping by format=flowed? What is your mail.wrap_long_lines and mailnews.wraplength setting?

Comment 4

[u328884]

Thank you, WADA. I will try to help...
-----
I don't know how to interpret bug 653342, your comment #14. My test case (paragraph of characters) is:

xxxxxxxxx xx xx xxxx (xxxxxxxxx xxxxxx xxxxxx xxxxxxxx) xxxxxxxxx - xx xxxxxxxx xxxxxxxxx xxxx xxxxxxxx. xx xxxxx xxxxx, xxxx xxxxxxxx xxxxx xxxxxx xxxxxxxxx xxxx xxxxxx xxxxxx xxxxxxxxxxxx. xxxxxx xxxxxxxxx, xxxxxxxxx xxxxxxx xxxx xxxxx xxxx xxxxxx xxxxxx xxxxxxxxxxxx, xxx xxx xxxxx xxxx xxx xxxxxxxx. xxxxx xxxx xxxxxx xxxxxx xxxxxxxxxxxx xx xx xxxxxxx xxxxx xxxx xx xxxxxxxxx xxxxxx xxxxxxxxxx xxxxxxxxxxx. xxxxx xxx 2 xxxxxx xxx xxxx: 1, xxxxxx xxx xxxxxxxxxx, xx 2, x xxxx (xxxxxxx xxx xxxxxxx) xxxx xxxxxxxx. xxx 1xx xxxx xx xxxxx xx xxxxxx x "xxxx xxxx-xxxx xxxxx". xxx 2xx xxxx xx xxxxxx x "xxxx xxxxxxxx xxxxx". xxxxxxxxx xxxxx xxxx xx xxx 1xx xxxx xx xxxxx. xxxx xxxxx xx'x xxxxxxx xxxxxxx xxxxxx xxx xxxxx xxxx xxxxxxxx xx xxx xxxxx xx xxxxxxxxxx xxxxxxxx. xxxxxxxxxxx, xxxxx xxx xxxxx xx xxxxxxxxx xxxxxxxxx xxxxxxxx (xxxxxxxx, xxxx xxxxxxxx) xxxxx xx xxxxxxxxx. xxxxxxxx xxxx xxxxxxxxxx xxxxxx xx xxx (xxxxx xx xxxx x xxxx) xxxxxx xxxxxx xxx xxxx xxxx-xxxx xxxxxx xxxx xxxxxxx xxxx zzzz xx xxxxxxxxx. xxxx, xxxxx xxxxxx xxxxx xxx xxx xxxxxxxx, xxxxxxxxx xxx xx xxxxxx xxxxxxx xxxx xxxxxxx. xx xxxxx, xx'x xxxxx xx xxxxx xx x xxxxxx xxxxxx xx xx xxxxx xx xxxxxxxx.

(Note the 'zzzz' word in the 3rd from the last 'sentence'.) This text appears to compose correctly, but AFTER it has been sent, it looks as below. (Note the 'zz'+'\n'+'zz' - the bogus 'new-line' occurs at char# 998 and, since 'new-line' in this case is 0x0D0A, this produces a total (bogus) line of exactly 1000 chars.)

xxxxxxxxx xx xx xxxx (xxxxxxxxx xxxxxx xxxxxx xxxxxxxx) xxxxxxxxx - xx xxxxxxxx xxxxxxxxx xxxx xxxxxxxx. xx xxxxx xxxxx, xxxx xxxxxxxx xxxxx xxxxxx xxxxxxxxx xxxx xxxxxx xxxxxx xxxxxxxxxxxx. xxxxxx xxxxxxxxx, xxxxxxxxx xxxxxxx xxxx xxxxx xxxx xxxxxx xxxxxx xxxxxxxxxxxx, xxx xxx xxxxx xxxx xxx xxxxxxxx. xxxxx xxxx xxxxxx xxxxxx xxxxxxxxxxxx xx xx xxxxxxx xxxxx xxxx xx xxxxxxxxx xxxxxx xxxxxxxxxx xxxxxxxxxxx. xxxxx xxx 2 xxxxxx xxx xxxx: 1, xxxxxx xxx xxxxxxxxxx, xx 2, x xxxx (xxxxxxx xxx xxxxxxx) xxxx xxxxxxxx. xxx 1xx xxxx xx xxxxx xx xxxxxx x "xxxx xxxx-xxxx xxxxx". xxx 2xx xxxx xx xxxxxx x "xxxx xxxxxxxx xxxxx". xxxxxxxxx xxxxx xxxx xx xxx 1xx xxxx xx xxxxx. xxxx xxxxx xx'x xxxxxxx xxxxxxx xxxxxx xxx xxxxx xxxx xxxxxxxx xx xxx xxxxx xx xxxxxxxxxx xxxxxxxx. xxxxxxxxxxx, xxxxx xxx xxxxx xx xxxxxxxxx xxxxxxxxx xxxxxxxx (xxxxxxxx, xxxx xxxxxxxx) xxxxx xx xxxxxxxxx. xxxxxxxx xxxx xxxxxxxxxx xxxxxx xx xxx (xxxxx xx xxxx x xxxx) xxxxxx xxxxxx xxx xxxx xxxx-xxxx xxxxxx xxxx xxxxxxx xxxx zz
zz xx xxxxxxxxx. xxxx, xxxxx xxxxxx xxxxx xxx xxx xxxxxxxx, xxxxxxxxx xxx xx xxxxxx xxxxxxx xxxx xxxxxxx. xx xxxxx, xx'x xxxxx xx xxxxx xx x xxxxxx xxxxxx xx xx xxxxx xx xxxxxxxx.
-----
Your para#2:
Yes, I use text-only mail composition.
"Why no wrapping by format=flowed?" I don't know what you mean. But if you are observing that, when I'm composing a reply, the original message does not wrap but instead extends to the right beyond the right-edge of the window... Yes that happens, and it makes replying extremely difficult. This has been a problem since I first started using TBird ...maybe 8 to 10 years ago. I've complained but it's never been fixed. I just put up with it.

mail.wrap_long_lines is a boolean = true
mailnews.wraplength is an integer = 0 (i.e., zero).

Comment 5

[WADA:World Anti-bad-Duping Agency]

In mail composition of Tb, if user intentionally sets mailnews.wraplength=0 or larger one than SMTP's line length limitation, I believe it's commitment of "I will be certainly responsible on SMTP's line length limitation" by user to Tb.
Even if general user, as far as people intentionally uses e-mail system, anyone should follow low of "e-mail is never text file".

Anyway, dup.