User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212 Pretty straightforward issue ... composing an email the word wrap setting inhibits the spacebar if the wrap value has been exceeded. It appears that there are other issues with long words and the wrapping functionality but this appeared when the spacebar keystroke happened to fall upon the 72nd character (which I have set to wrap at 72 characters). Reproducible: Always Steps to Reproduce: 1. Set wrap to 72 characters. 2. Type 71 characters and then hit spacebar Actual Results: 1. The character seems to be retained in the buffer of keystrokes because you have to hit delete twice to actually delete what appears on the screen. However, the display doesn't wrap correctly. Expected Results: The carat for key entry should have moved to the beginning of the next line.

Looks like another format=flowed glitch. Testing this, I find this situation: ...text | <-wrap column at the bar, three spaces from end of line If I type spaces at that point, the carat advances one, two, three spaces, then on the fourth space collapses back to the end of 'text'. If I type a total of five spaces plus text, the composed message appears to have the second line flush left. The sent message is displayed as follows: 1) if the window edge wraps the message such that the 'text' appears in the middle of the line, there are three spaces (not five) separating it from the following text. 2) if the window edge leaves room for 'text ' (text plus three spaces), but not enough for the following word, the second line is flush left. 3) if the window edge leaves room 'text ' (including one space) but not for three spaces, there are two leading spaces before the second line: one space used on the line, two spaces moved to the next line. This is related to bug 125928, but I couldn't find any duplicates.

After some more testing on this bug, I am retracting my claim that this has to do with format=flowed. The mail compose window behaves the same whether f=f is turned on or not. I also no longer think that bug 125928 is related. However, the source text of the message that is transmitted does vary depending on whether f=f (mailnews.send_plaintext_flowed) is turned on; this is described in bug 223279.

*** Bug 224214 has been marked as a duplicate of this bug. ***

This bug is the mail/news version of the core editor bug 87314.

*** Bug 249193 has been marked as a duplicate of this bug. ***

This is a bit anoying. When writing mail you never know how many spaces there are at the end of line or is there space at all. Why can't it behave like Notepad or any other text editor?

Now it behaves so you can just keep typing spaces and it only wraps, if you type a letter. Thunderbird 52.1.0 (32-bit) Windows 7 64-bit