24930 - Reply and wrap text in window fails

Status: RESOLVED WORKSFORME

(MailNews Core :: Composition, defect, P3)

Description

[Ninoschka Baca]

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.

Comment 1

[Jean-Francois Ducarroz]

Rich, Akkana, any idea?

Comment 2

[Jean-Francois Ducarroz]

Accepting

Comment 3

[Akkana Peck]

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).

Comment 4

[lchiang]

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

Comment 5

[Akkana Peck]

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.

Comment 6

[Ninoschka Baca]

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.

Comment 7

[Akkana Peck]

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.

Comment 8

[Jean-Francois Ducarroz]

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...

Comment 9

[Jean-Francois Ducarroz]

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.

Comment 10

[Ninoschka Baca]

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

Comment 11

[Jean-Francois Ducarroz]

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

Comment 12

[Ninoschka Baca]

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?


  

Comment 13

[Jean-Francois Ducarroz]

moving to M15

Comment 14

[Jean-Francois Ducarroz]

Fixed and checked in

Comment 15

[fenella]

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.

Comment 16

[fenella]

Assign it to myself.

Comment 17

[Akkana Peck]

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.

Comment 18

[Jean-Francois Ducarroz]

Accepting

Comment 19

[scottputterman]

moving to M18 and nominating for beta3.

Comment 20

[selmer (gone)]

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

Comment 21

[Akkana Peck]

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.

Comment 22

[lchiang]

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

Comment 23

[fenella]

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.

Comment 24

[scottputterman]

sorry for the extra email. Removing mail2 keyword.

Comment 25

[John Malmberg]

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.

Comment 26

[Hixie (not reading bugmail)]

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.

Comment 27

[Mike Pinkerton (not reading bugmail)]

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.

Comment 28

[Akkana Peck]

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).

Comment 29

[Mike Pinkerton (not reading bugmail)]

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

*shrug*

Comment 30

[esther]

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.  

Comment 31

[esther]

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.

Comment 32

[Michael Buckland]

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