Closed Bug 17983 Opened 25 years ago Closed 25 years ago

Plain text reply, doesn't quote the message

Categories

(MailNews Core :: Composition, defect, P3)

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: esther, Assigned: rhp)

References

Details

Using 19991003 builds on win98, mac and linux when Replying using Plain text,
the cursor doesn't appear above the text to be quoted, and carriage return
doesn't work (17908), but this part is unreported for plain text I think:  Text
is not quoted when viewing the reply.  New text continues on the same line as
the text that should be quoted.

1. Launch Messenger
2. Set you account to plain text compose
3. Select a message
4. Click Reply

Result: you don't see the original text, resize then you will see it and cursor
is flashing at the end of the original text. If you are able to move it to above
the original text and start typing then send when you receive and view the
message the new text starts at the end of the original text.

Expected:  The original text to be visible without resizing the compose window,
the cursor to be place above the original text, and when viewing the reply
message the new text to be above the original text with the original text
quoted.
QA Contact: lchiang → esther
OS: other → All
cc: momoi since you guys use plain text a lot :-)
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Target Milestone: M11
Works fine with today's build. The reply is correctly "quoted", line breaks are OK and display is OK too.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
reopening, this is not working in builds 19991104-16 on win98, and 1999110408 on
mac and linux for Plain text.  Actually things got worse for win98, I don't see
the original text at all (while composing the Reply or viewing the Sent reply).
With mac and linux the bug change a little (CR works somewhat), but basically
plain text reply does not quote the original text and puts the new text on same
line as original text.
Esther, when you say you don't see the original text. Did you reply to a message
in your local mail account? (doesn't work. bug 17956), POP account or IMAP
account?

I filed another bug for the CR problem, bug 18100.
My POP account and my IMAP account.  I'm downloading today's build right now, I
will recheck this with that build and update the bug.
I retested with today's build (1999110509-win32, 1999110508-mac and linux) on
all 3 platforms and I don't see the original text when in the compose window of
the message I'm replying to (in plain text only), I also don't see the original
text at all in viewing the sent reply.   This is now broken on all 3 platforms.
Strange, I cannot reproduce the problem either on my Mac or my PC with a build
from this morning. I've tried to install the official build (Windows) from the
ftp server but the installation failed with error -204.

Esther, does this append with any message? with only HTML message or TEXT
message?
There appear to be quite a few things broken with plaintext editing and with
pasting/inserting of quotes in plaintext (someone disabled it some time ago and
I just discovered that).  But I'm not sure the reply code is actually calling
the editor quotation code anyway, since what I see in the plaintext mail compose
window (quotation indented by a few spaces) doesn't seem consistent with what I
see in the plaintext edit window (quotation inserted as an html quotation).
Adding self and a couple other people to the cc list.
With today's builds 1999110808 on win & mac (haven't tested linux yet).  I still
have a problem with the original text missing when replying.  Additional
information that may help you reproduce both the missing original text and the
non-quoting.
1.) Reply in PLAIN text mode to a PLAIN text message the original text is
missing.
2.) Reply in PLAIN text mode to an HTML message,  the original text is there but
is not quoted.  Note: the cursor is placed at the end of the original text so if
user starts typing the new text appends to original text, if user moves the
cursor to 2 lines above original text on Win32 the text ends up on the same line
as original text
On today's Linux build, when replying to either a plaintext or html message with
plaintext compose, I see the original text intented by two spaces (no "> ").
Akkana: I'm still having problem with the InsertAsQuotation() in:

         mozilla\mailnews\compose\src\nsMsgCompose.cpp

See the comment with your name in it :-)

- rhp
Reply in plain text mode has never put the ">". We only indend the original
body.
Update:  I tried something new, I sent a plain text message from 4.7 and then
opened it in Sea 11-08 mac build, and clicked reply- the original text was
there.  So there may be combined problems (plain text send from seamonkey build
on 11-8 doesn't disply the text when  doing a plain text reply to that message.
So for those who can't reproduce this yet, send a plain text message using 11-08
build and then open it and click Reply (with this scenario, I don't see the
original text).
Ah, the Unicode problem.  Naoki has a fix for that, which along with my
re-enabling of Insert/PasteAsPlaintextQuotation, which we will check in when the
tree opens.
When Mozilla sends out Plain Text mail, it creates a Content-Type header like the followingL

Content-Type: text/plain; charset=us-ascii; format=flowed

The problem seems to be "format=flowed". When you eliminate this part of the Content-Type header, reply/quoting
works OK. Also 4.71 will generate only:

Content-Type: text/plain; charset=us-ascii

Mozilla does not generate "formatr=flowed" for HTML mail, however. And so if the original message from Mozilla
is of HTML type, this problem does not seemt to occur.
So why are  we generating the extra Content-Type parameter and what is it for?
Hello everyone,
Don't put too many cycles into this one until after the tree opens up again. I
know of changes for "format=flowed", quoting and I18N issues that will fix many
of the problems here. (i.e. Quoting is working fine in its many forms in my
build)

- rhp
Assignee: ducarroz → rhp
Status: REOPENED → NEW
Reassign to rhp
Status: NEW → ASSIGNED
I think I have this fixed. I would like to get it into the tree before a
branch. I will try to have this reviewed and get approved for checkin later
this evening.

- rhp
I have a reviewed fix in my tree...waiting for approval to checkin.

- rhp
Status: ASSIGNED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
Blocks: 18471
*** Bug 17485 has been marked as a duplicate of this bug. ***
*** Bug 14748 has been marked as a duplicate of this bug. ***
*** Bug 14748 has been marked as a duplicate of this bug. ***
Blocks: 13574
Using build 1999111017 on win and linux the text is now displayed in the reply
window, but when viewing the reply after sending the new text is not separated
from the original text.  It starts on the same line as the original text.  Note:
when composing the reply I positioned the cursor 2 lines below the original
text: on Linux it looks OK but on Windows 98 there is a square at the beginning
of each of these 2 blank lines.  Was this fix just for displaying the text,
the second part (viewing the replied text)is not fixed?
This fix should affect the text that's sent out as well.

When you send a reply, how does the result look when you view it in 4.x?  If I
use today's build to reply to a message in plaintext, and send the reply, it
looks fine when viewed in 4.61 except for some bad wrapping of the quoted text
(which I've filed as bug 18576 and will be looking at asap), but when I try to
view it in Mozilla, I get a slew of asserts from mimetpfl.cpp about "corrupt
line end", the "convert from plaintext to html" code kicks in (may or may not be
related to the asserts) and what I see in the message pane is mixed html-quoted
and unquoted lines (reasonable, it's confused by the bad wrapping) but the new
text does start on its own line, so it sounds different from what Esther is
seeing.

The issues are probably different from the ones in this bug report, so I'd
suggest filing a new bug, but cc'ing the same people who are on this bug report
in case it turns out to be related after all.

Esther, when you're composing the reply, if you do Debug->Output Text (that's
available even in optimized builds, I think), does the message look okay, or
does it already have the problem you described?  If it looks okay in OutputText
(except for the wrapping problem) but not okay after it's sent, the new bug
should probably go to rhp, but if it looks wrong even in OutputText, assign it
to me (but cc both of us in either case).
There are a couple of bugs which deal with problems mentioned
by esther. Here they are:

Extraneous characters (e.g. square box) in quoted text
under plain text send option --> Bug 18409.

Line ends are lost when quoted text is received --> Bug 18249
Akkana,  OK, I did a plain text reply to a plain text message 2 ways:
1. I put in 2 carriage returns after the original text, then I viewed it using
Debug Output Text and it displayed with 1 line between the original text and new
text, I then sent it and viewed it in 4.7 and it displayed with 1 line between
the original text and new text.
2. I just clicked in the body of the message (for windows the cursor was place
after the square in the 2nd blank line below the original text) (for linux the
cursor was placed on the 2nd blank line below the original text) and when I
started typing, the text was entered on the third line for both, when viewing
the debug output, it was all on one line. After sending and viewing in 4.x all
text was on the same line.   So it looks like adding one or more Carriage
returns will actually separate the old text from the new with 1 line.
Might be an editor problem, if the editor is showing you blank lines but they're
not making it into the output.  Go ahead and assign a new bug to me and I'll
investigate; it doesn't sound like it's related to the mime problems I was
seeing on replies.  I just started hitting the crash in tree code that I've
heard other people talking about, so I'm having trouble getting the app to stay
up long enough to duplicate what you're seeing, but I'm sure a fix for that will
be coming along shortly.
Target Milestone: M11 → M12
Oh, great.  I got the fix for the table problems so that I could run today's
build, and dicovered that for some reason, my cvs commit yesterday didn't
actually go in (though I didn't imagine typing it -- it's still in my shell
history list) so the fix for quoting didn't actually get into today's builds.
I've just checked it in again; crossing my fingers that it will actually go in
this time.  Esther, you should see the fix in tomorrow's builds (M12, I'm not
sure why this bug was marked M11).
I think it was marked M11 when the bug changed to the text not showing up at
all (per comment 11/05 14:16).  With that part fixed I think M12 is OK too.
Status: RESOLVED → VERIFIED
Using build 1999111909 on win98 and 1999112008 on Mac and Linux plain text reply
quotes the original message and new text is placed on a different line (see
comment 11/08/99 11:28).  Square box issue is fixed too (see comment 11/14/99
11:30) I tested this by replying to plain text messages and html messages in
plain text mode.  Linux has some problems with extra quoting bar and
inconsistancy of location of new text, but I will log a separate bug for that.
Verified
No longer blocks: 18471
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.