This problem was originally reported as a second item in bug# 21458 by Fenella. Linux (1999-12-21-08 M13) Win_nt 4.0 (1999-12-21-09 M13) Mac (1999-12-21-08 M13) When using HTML editor to reply, the original content wrap text to fit in window but the new text does not wrap text when resizing the window. When using Plain text editor to reply both the original and the new text does not wrap to fit in window when resizing the window. _____________________________________________________________________ Using todays build the results are a little different Build 2000012401M13: NT4, Linux, Mac - Reply in HTML mode wraps the original text and new text using Windows, Linux and Mac. - Reply in Plain mode does not wrap the original text or new text using Windows, Linux and Mac.

Rich, Akkana, any idea?

Accepting

Yes -- it broke quite a while ago, and I filed bug 22502, which is still open. Last I checked, it actually did wrap, but at roughly double the number of characters specified in the body style (so to the user, it might as well not be wrapping at all).

akkana - does that bug you just fixed today (and will check in tomorrow) also fix this? I don't have that bug number handy.

No, from the description this sounds like 22502, which was fixed a long time ago. The bug I'm working on (bug 28279) is that quoted text does get wrapped, incorrectly.

Build 2000-02-23-08M14: NT4, Linux 6.0 The original problem still exists. After replying and typing additional text, the old and new text wraps. But as stated in the original description, if I resize the window then the text does not wrap.

It doesn't wrap at all? Text in a plaintext compose window is supposed to wrap to 72 columns (or whatever your pref sets it to be, if ducarroz has implemented that pref yet), regardless of your window size (part of being wysiwyg and trying to show you exactly what the message will look like when it's sent -- I saw lots of complaints about the lack of that in 4.x), so if you resize smaller than that, you'll see a horizontal scrollbar. This seems to be working as intended for me on Linux.

When I set the wrapColumn, I get the following error: ### window.editorShell.wrapColumn exception text: [Exception... "Component returned failure code: 0xc1f30001 (NS_ERROR_NOT_INITIALIZED) [nsIEditorShell.wrapColumn]" nsresult: "0xc1f30001 (NS_ERROR_NOT_INITIALIZED)" location: "JS frame :: chrome://messengercompose/content/MsgComposeCommands.js :: ComposeStartup :: line 219" data: no] - failed maybe I should try to set it later in my initialization process...

Setting the wrapColumn once the document is loaded fix the problem. Now my text correctly wrap at column 72 (default value) what ever is the window width.

Build 2000-03-09-13M15: NT4, Linux, Mac It is also working for me.

Wait a minute, what's working for you? I haven't checked in my fix yet!

By fixed I was referring to Akkana's question: 1. Viewing a message from the 3-pane - html text wraps as I resize the window. - plain text displays a horizontal scrollbar so you are able to read the text that is off the screen. 2. Reply to a message and type new text - html text wraps as I type new text and it also wraps if I resize the Compose Message window. - plain text appears to not wrap and then it does but some of the text is off the screen. In this case a horizontal scrollbar appears so I can scroll to see any text that appears off screen. The part that does not work is going into preferences to set a number for the text to wrap. No matter what I set the number to, it doesn't appear to make a difference when composing a message. Is this what you are referring to?

moving to M15

Fixed and checked in

Linux (1999-04-12-12 M15) Win32 (1999-04-12-06 M15) Mac (1999-04-12-05 M15) When using HTML editor to reply, the original content wraps text to fit in window and NOW the new text wraps text when resizing the window. This now works as expected on all 3 platforms. On Win_nt 4.0: When using Plain text editor to reply both the original and the new text wraps when it reaches 72 characters in width. And when I viewed the replied message, it wraps to fit in window when resizing the window. This works as expected. On Mac and Linux: When using Plain text editor to reply, both the original and the new text starts a new line when it reaches 72 characters in width. And when I viewed the replied message with the screen width larger than 72 chars, it does not wrap to fit the window when resizing the window. 72 chars on each line are displayed even though the window size can fit in more chars. And then when I viewed the replied message with the screen width smaller than 72 chars, it creates a scroll bar at the bottom so that it allows me to scroll to the right to view the rest of the message. This DOES not work as expected. Ducarroz, Akkanna told me that plain text should have a fixed width of 72 chars. If that is the case, Linux and Mac are fine, and I can close the bug. Please advise me what fix you have done so that I know what to expect. There has been a lot of confusions in wrap text issues. I'll re-open this bug pending your reply.

Assign it to myself.

If they're not doing the same thing on all platforms, then something is definitely wrong. Sounds to me like Mac and Linux are doing the right thing for plaintext and Windows is wrong, but that may be a format=flowed issue (maybe Windows is doing the right thing for format flowed? If so, what should a Windows user do if they want to do normal plaintext?) BTW, now that there's a pref for text width, the fixed width should presumably be the width that the pref says, not necessarily 72, unless we haven't implemented that yet.

Accepting

moving to M18 and nominating for beta3.

Can someone add a clear statement describing exactly what remains to be fixed?

The clear statement is that the three platforms aren't doing the same thing even though all the code is supposed to be XP. See Fenella's analysis of 4/12/2000. Which behavior is correct depends on whether we're doing flowed or fixed by default. I'm not sure which way the decision went. This should probably be checked in on each of the three platforms, with the default and then with the opposite of the default.

Fenella - can you check on this to see what the default is?

In the ../defaults/pref/mailnews.js file, it shows the default is "Flowed" pref("mailnews.send_plaintext_flowed",true) RFC 2646. pref("mail.wrap_long_lines", true) on all platforms.

sorry for the extra email. Removing mail2 keyword.

This bug appears on build ID: 2001112014 for the OpenVMS platform. Normally the text wraps, but occasionally the lines do not wrap. Also when manually wrapping lines by inserting a hard return, an additional blank line is inserted that should not be there. This line can not be deleted. Even on the occasions that the blank line is deleted in compose mode, it shows up on the sent message.

Precise steps to reproduce: 1. Reply to the "NEW Pot Substitute!" spam (or most other messages). 2. Select from the second line of the quoted text to the last but one line of the quoted text. 3. Press delete. 4. Type "sgdjifslkj sdflkj sdlfkj sdlkfj sdlkjf sldkjf sdlkjf sldkjf sldkf sdkjhf sdifhsd kjfhsd kjfh sdkjhfsdkjhf sdkjf hsdkjhf skdjfh sdkjfh sdkjf hsdkjfh sdkjfh sdkjhf sdjkhf sdkjhf ksdjhfsdk jhfdskjfsdh". Results: Text should wrap. It doesn't.

this is a serious bug, imho, and my single biggest complaint with mail-compose. it also makes us look like amatures. sure, you can always rewrap the email, but that assumes you know about Options:Rewrap (which i just learned about this morning). Most users will just take a look at this and toss the software in the trash.

Pink and Hixie: if you're talking about "delete text in plaintext compose and your caret ends up inside a block that's not wrapped", which is what it sounds like, I think you want bug 83378 (assigned to jfrancis) and should transfer your keywords and nominations to that bug. This bug is for platform differences (apparently in both text and html compose?) that no one has actually looked at in over a year (not clear whether they're still a problem or not).

has this bug then morphed into something different? the original bug report sounds almost exactly like 83378. *shrug*

UPDATEA: Using windows build 20020218 on winxp Mac build 20020212 on mac os9.1 I composed a new message in HTML typing text until the text wrapped at the window width, continuing with several lines then hard <enter> to continue to another bullet item. =OK I composed a new message in plain text typing until the text wrapped at the preference designated with of 72 characters, continuing with several lines then a hard line break <enter> =OK Replying to both of the messages above in plain text and html does the right thing when typing in text within the message body. I haven't finished testing Linux yet or trying copy and paste. Note: This bug may have several other bugs in it like 68087 for the extra line when replying in HTML mentioned in comment #25. At this point I'm trying to get this closed based on the original scenario and have separate bugs for what's left.

OK, after finishing my testing all aspects of this bug here's what I have: 1.)This bug Fixed-The original scenario is very old and could have be a bug then, but is not a bug now. Note: it doesn't mention selecting, deleting and then retyping text so bug 83378 which still exists is not part of the original reported bug. 2.)Bug 83378 still opened not part of this bug anymore. 3.)New bug to be logged 126715-The original bug didn't mention if this happens while viewing a replied message or composing it. The reason I mention this is because we still have a problem mentioned in comment #15 where Plain Text messages (no matter if they are replied or new msgs) when displayed on Windows platforms only, stays with the width limit used during the composition, even if the viewing window is wider than 72 characters. As Akana points out in comment #21 this is different behavior amoung the platforms for viewing the same plain text message. (Linux and mac will display the text beyond the 72 character limit set during composition) Note: all platforms have "wrap text to fit window width" checked for displaying plain text messages.

Discussed in 2/25 bug meeting with Mktng, PjM, Engineering. Decision to resolve worksforme. See Esther's previous comments.