Closed
Bug 68087
Opened 24 years ago
Closed 22 years ago
extra > lines are added when replying in plain text to HTML mail
Categories
(MailNews Core :: Composition, defect, P2)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla1.0
People
(Reporter: kazhik, Assigned: bugzilla)
References
Details
(Keywords: regression, Whiteboard: Outlook,)
Attachments
(2 files, 4 obsolete files)
2.20 KB,
text/plain
|
Details | |
615 bytes,
patch
|
bugzilla
:
review+
bugzilla
:
superreview+
asa
:
approval+
|
Details | Diff | Splinter Review |
Extra > lines are added when replying to HTML mail. (1) Send a HTML mail with Outlook Express. (2) Receive it with Mozilla Mail. (3) Hit Reply button. Extra ">" lines are added for each original lines.
Reporter | ||
Comment 1•24 years ago
|
||
WORKSFORME with 2001021108/Win98.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
VERIFIED, WFM.
Status: RESOLVED → VERIFIED
Reporter | ||
Comment 3•23 years ago
|
||
This bug appeared again on 2001050808/Linux.
Assignee | ||
Updated•23 years ago
|
Status: REOPENED → ASSIGNED
Whiteboard: Outlook
Target Milestone: --- → mozilla1.0
Assignee | ||
Comment 6•23 years ago
|
||
Reporter, do you still have this problem using a recent build?
Reporter | ||
Comment 7•23 years ago
|
||
Yes, nothing have changed.
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla1.0 → mozilla0.9.7
Comment 8•23 years ago
|
||
Very nasty bug. I've been replying to emails and the line breaks double or quadruple after each normal line in the message.
Comment 9•23 years ago
|
||
Is Moz detecting a wrong format and trying to convert HTML as plaintext to HTML? Such as <br>\r\n to <br><br> ???
Updated•23 years ago
|
Target Milestone: mozilla0.9.7 → mozilla0.9.9
Comment 10•23 years ago
|
||
Adding nsbeta1 keyword to all regressions so they *get some love* and attention.
Keywords: nsbeta1
Updated•23 years ago
|
Target Milestone: mozilla0.9.9 → mozilla1.0
Assignee | ||
Comment 11•23 years ago
|
||
Reporter, can you attach a sample message to help reproduce this problem. Thanks
Reporter | ||
Comment 12•23 years ago
|
||
Comment 13•23 years ago
|
||
I am 70431's reporter. You can see a sample in 70431 #1 id=26383. It is a sample message. Unzip and move it under Local folders. Launch Mozilla and choose it and reply to it. Note this symptom occurs only when original message is html and replying message is plain text.
Reporter | ||
Comment 14•23 years ago
|
||
0.9.8/Win2k has this bug, but 2002021803/Win2k works fine.
Assignee | ||
Comment 15•22 years ago
|
||
using the test case in bug 70431, I am able to reproduce the problem...
Summary: extra > lines are added when replying to HTML mail → extra > lines are added when replying in plain text to HTML mail
Assignee | ||
Comment 16•22 years ago
|
||
This is a problem with nsPlainTextSerializer. An extra new line is added after each div block. div blocks should be like blockquote, just ensure we go the next line but do not add an extra new line.
Assignee | ||
Comment 17•22 years ago
|
||
closing a div should not add a blank line
Assignee | ||
Updated•22 years ago
|
Whiteboard: Outlook → Outlook, have fix, waiting reviews
Comment 18•22 years ago
|
||
Looks sensible to me, r=akkana. But Tanu owns the serializers, so I'm cc'ing her in case she has any comments.
Assignee | ||
Comment 19•22 years ago
|
||
thanks akkana, I'll ask Tanu to review it as well...
Comment 20•22 years ago
|
||
Akkana, "div" tag is not there in IncludeInContext() so it should not be the cause here and even with the patch, I see an extra |>| at the end. I've a doubt here. Bug says: "Extra ">" lines are added for each original lines." On WinNT, I don't see it for all the lines. It's just one extra ">" at the end.
Assignee | ||
Comment 21•22 years ago
|
||
Tanu, in order to see the problem, you must reply in plain text to the attached HTML message.
Comment 22•22 years ago
|
||
Sorry, I just tried sending it as HTML and was confused with IncludeInContext() part. Patch works fine for me too. I don't see any side effect to other test cases. But while sending as HTML I still see an extra ">" at the end. Probably not related to this one. Something to be done with nsHTMLContentSerializer...
Assignee | ||
Comment 23•22 years ago
|
||
The extra line at the end of the message is another issue for which I have a bug already. Thanks for testing the patch.
Comment 24•22 years ago
|
||
Comment on attachment 72673 [details] [diff] [review] Proposed fix, v1 sr=jst
Attachment #72673 -
Flags: superreview+
Assignee | ||
Updated•22 years ago
|
Attachment #72673 -
Flags: review+
Assignee | ||
Updated•22 years ago
|
Whiteboard: Outlook, have fix, waiting reviews → Outlook, have fix, waiting approval
Comment 25•22 years ago
|
||
Comment on attachment 72673 [details] [diff] [review] Proposed fix, v1 a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #72673 -
Flags: approval+
Assignee | ||
Updated•22 years ago
|
Whiteboard: Outlook, have fix, waiting approval → Outlook, have fix, ready to go
Assignee | ||
Comment 26•22 years ago
|
||
Fix checked in
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 22 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 27•22 years ago
|
||
*** Bug 128407 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 28•22 years ago
|
||
The fix wasn't enough. Reopening bug.
<div>ABC</div>
DEF<br>
This is quoted as:
> ABC DEF
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 29•22 years ago
|
||
This patch fixes both this original bug and the bug of comment #28.
Assignee | ||
Updated•22 years ago
|
Status: REOPENED → ASSIGNED
Whiteboard: Outlook, have fix, ready to go → Outlook, have fix, need review
Comment 30•22 years ago
|
||
What you're doing makes sense and I approve of the concept (i.e. EnsureVerticalSpace(0) makes more sense than 1 for a div). I probably would have put the test outside the blocklevel check, though, along with the other tag checks; why spend time checking for blockness if we're just going to check for a specific tag later? But Tanu will be in this code the most and has the final say on details like that.
Comment 31•22 years ago
|
||
I agree with Akkana for putting the test outside. Would you please try the test outside with no check for formatting(i.e. mFlags & nsIDocumentEncoder::OutputFormatted) and following the floating lines concept similar to the other tags.
Comment 33•22 years ago
|
||
Yes but now we don't need "EnsureVerticalSpace(0);" in the patch and need to test it well.
Comment 34•22 years ago
|
||
I removed EnsureVerticalSpace(0). This patch works fine for me.
Attachment #75363 -
Attachment is obsolete: true
Comment 35•22 years ago
|
||
Comment on attachment 75367 [details] [diff] [review] a patch v3 Looks fine to me, r=tmutreja.
Attachment #75367 -
Flags: review+
Updated•22 years ago
|
Attachment #72673 -
Attachment is obsolete: true
Comment 36•22 years ago
|
||
Comment on attachment 75367 [details] [diff] [review] a patch v3 sr=jst Please remove the empty line before the "else if ..." when checking in though.
Attachment #75367 -
Flags: superreview+
Comment 37•22 years ago
|
||
Thanks, Johnny. I removed an empty line.
Attachment #75367 -
Attachment is obsolete: true
Assignee | ||
Updated•22 years ago
|
Attachment #77001 -
Flags: superreview+
Attachment #77001 -
Flags: review+
Comment 38•22 years ago
|
||
Comment on attachment 77001 [details] [diff] [review] a patch v4 a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #77001 -
Flags: approval+
Assignee | ||
Comment 39•22 years ago
|
||
Fix checked in. Thank you Shotaro Kamio for providing the patch.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
Whiteboard: Outlook, have fix, need review → Outlook,
Comment 40•22 years ago
|
||
Using the test case in bug 70431 and build 20020408 on winxp & linux and 20020402 on mac os9.1 and os 10.1 this is fixed verfied.
Status: RESOLVED → VERIFIED
Comment 41•22 years ago
|
||
*** Bug 112563 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•