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)

Product:
MailNews Core
Component:
Composition
Type:
defect

Tracking

(Not tracked)

Status:
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 ago → 25 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.