Open Bug 1707169 Opened 4 years ago Updated 3 years ago

Text email wraps dynamically on send, or when received, but not both

Categories

(Thunderbird :: Message Compose Window, defect)

Thunderbird 89
x86_64
Windows 10
defect

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: mneme, Unassigned)

Details

Attachments

(2 files)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.128 Safari/537.36

Steps to reproduce:

Send plain-text email with the following settings:

mailnews.wrap_long_lines=true (don't mess with my outgoing emails; just let them go as long as they need)
mailnews.wraplength=0 (don't have a specific line length; just wrap to the window length)
plain_text_wrap_long_lines=true (wrapping is great, particularly in the client)
mailnews.send_plaintext_flowed=true (regardless of what I send, the recipient should be able to rewrap it so it flows comfortably in their screen)
mailnews.display.disable_format_flowed_support=false (don't disable flowed text; I like flowed text).

Actual results:

Composing, it's flowed and wraps to the window length.
But sending, the text sends as one long line. Receiving it as thunderbird, it shows up as one long line and you need to scroll to see it.

Expected results:

The composing behavior is correct.
But the sending (or possibly the display) behavior is not. With format=flowed it should send flowed, not unflowable (the receiving headers do have format=flowed, but thunderbird seems unable to flow it for other reasons; I haven't tested this with gmail, so it's possible it's a pure display bug in Thunderbird).

With one change:

As above, but:
mailnews.wraplength=78

(or any other positive integer), the display in compose is wrapped to the length (as documented), but the received email rewraps to the sent text as desired.

Ideally, the flow point on send should be divisible for format=flowed text emails from the display feature (so you can flow as desired during compose but send in a fashion that's compatable with old text email clients that don't support flowed and have 72 character windows). But either way, changing a display option shouldn't break format=flowed when sending!

In the beta (89.0b1) the send with mailnews.wraplength=0 is the same, but the viewing pane handles it much better, wrapping the text to window size as desired.

It would be better still if there was a way to have it wrap the text to some smaller line length in transfer for compatability purposes, but that's a feature request, not a bug.

A minor display issue is that while in viewing pane, quoted text (with one or more > in the left hand side) is properly displayed as a quote when wrapped, in the composition pane it is not, so it's not clear it will work correctly until send.

Component: Untriaged → Message Compose Window
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64
Version: 78 → Thunderbird 89

Receiving it as thunderbird, it shows up as one long line and you need to scroll to see it.

Can you please attach such a message that doesn't get wrapped upon display: Save the message as eml file, remove any personal information, then use the "Attach New File" button. There are different encodings and content-transfer-encodings, so it would be hard to reproduce. In TB 78 I get this:

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.10.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test 
test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test

So one line that is 990 characters long and a shorter one, but it is displayed correctly, I don't need to scroll to the right. Your example may look completely different.

Sure. The uploaded file was generated by TB80b.

It wraps correctly on TB80b.

It certainly doesn't wrap at the window boundary on TB78, although the very long quoted line wraps once (two lines) on 78, at around the 1275 character boundary (it's possible that if I'd sent a >1275 unquoted it would also wrap at that boundary; not sure).

Attached image 1707169-wrap.png

This is what I see in TB 78. The message you attached is format=flowed with the first line of 160 chars, the quote with 335 chars. There are no 1275 chars anywhere.

The wrapping of the message to the window boundary should be the same in basically all versions of TB I know, after about TB 24. I haven't looked when format=flowed support was introduced, but it's been here a very long time.

What makes your system different? The prefs you mentioned are at their default value apart from mailnews.wraplength which affects plaintext composition, but not display. BTW, it's mail.wrap_long_lines. If I set that to false, then I get two long lines displayed, and I need to scroll to the right to see it. It still gets wrapped at 278 chars.

BTW, TB 89 behaves the same as TB 78 for me.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: