User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

1. Entered text with lines longer than 80 characters into task description

Alternatively, editing an existing task description with long lines does it too

Actual results:

1. Now in the preview window, the task description shows word-wrapped to 80 column with, even if the actual preview window is much wider.

2. After doubleclicking on it to open the edit window again, the text still shows with the original long lines (as it should).

Expected results:

1. The preview window should just show the text as is. If it needs to wrap it, please only do it on its actual width, and not at 80 characters.

It's a task description, not a mail message!

Reproduction:

1. Create a new task
2. In the description, enter many words with a total of 100 or more characters, in a single line
3. -> The line is long and wraps at the end of the editor window
4. Save
5. Click on the task, to view it in the preview window

Actual results:

• The long line breaks at 80 characters.

Expected result

• The long line breaks at the window width
• If I change the window width, the linebreak of the long line adapts.

Still an issue in Thunderbird 91.8.0

If some people actually want these spurious line breaks, can we have a discoverable config setting to optionally get old behavior back (unaltered text shown in read-only view)

Actually, it's not just a display thingy but it's stored that way.

Case in point:

1. Enter a task description with a "long line" using thunderbird 78.14.0 into a network based calendar => it is still shown correctly (in 78.14.0) after "Save & Close"

2. Look at it in thunderbird 91.8.0 => it is still shown correctly (i.e. long line still unbroken)

3. Doubleclick on it to do a trivial edit (in 91.8.0) (such as append 2 characters at the end), and "Save & Close" => the line is now broken in 2.

4. Look at it in thunderbird 78.14.0 (you may need to do RightClick->SynchronizeCalendar) => the line is still shown broken, even in the editor.

=> this makes all this only worse, as the data is actually mangled "on disk" (or in database), not just for display.

Still an issue in 91.13.0

What is taking so long?
This bug has been open since 7 months, and the first of this series (same probable root cause) has been open since December 12th 2021!