158918 - line break needed after quote line ("... wrote:") when quoting original message using Options->Quote Message

Status: RESOLVED WORKSFORME

(MailNews Core :: Composition, defect)

Description

[J Luh]

When you use Options->Quote Message to quote the original message in a reply,
Mozilla fails to add a line break after the quote line. I have experienced this
with 1.1b on Windows XP and Mac OS X.

To reproduce:
1. Uncheck "Automatically quote the original message when replying" in Mail
Composition prefs.
2. Begin composing a message reply.
3. Choose Options->Quote Message.

What happens:
original message appears like this:

Sender wrote:>message here
>

What should happen:
original message should be appear like this:

Sender wrote:
> message here
>

Comment 1

[Pascal Chevrel:pascalc (PTO until April 26)]

Confirming with build 2002081209 and mozilla 1.0

The problem only appears if compose window is set to use plain text only. It
works with HTML.

Comment 2

[Pete Zha]

taking

Comment 3

[Felix Miata]

Looks to me like dupe of Bug 91576 or Bug 67391

Comment 4

[J Luh]

This is not a duplicate of either of those bugs. Bug 67391 Bug 91576 is asking
for an extra newline (2 newlines) between the quote line and the quoted text.
Bug 67391 is talking about newlines added where they should not be.

Comment 5

[Felix Miata]

I missed the one I really meant, bug 109935.

Comment 6

[Jon Roland]

This may be a place to suggest my preference that the user have the option of
selecting a "bracketed" quote, surrounded by lines of preselected bracket
characters, instead of an indented quote, and be enabled to pre-select the
bracket or indent characters. Bracketing preserves the nested quote structure
while enabling readers to more easily copy and paste quoted material without
having to remove the indent characters, and avoids the wrapping of deeply nested
quoted lines.

Comment 7

[Jo Hermans]

*** Bug 176993 has been marked as a duplicate of this bug. ***

Comment 8

[Pete Zha]

Attachment: use nsIPlainTextEditor if not in html mode

Comment 9

[Pete Zha]

Comment on attachment 106079 [details] [diff] [review]
use nsIPlainTextEditor if not in html mode

request r=/sr=...

Comment 10

[Pete Zha]

CC ducarroz and bienvenu for r= and sr=

Comment 11

[Jean-Francois Ducarroz]

Comment on attachment 106079 [details] [diff] [review]
use nsIPlainTextEditor if not in html mode

Thanks for fixing this problem. R=ducarroz

Comment 12

[David :Bienvenu]

Comment on attachment 106079 [details] [diff] [review]
use nsIPlainTextEditor if not in html mode

sr=bienvenu, but it looks like the prevailing braces style is 
if ()
{
}
else
{
}
not if () {
}else {

so please fix that before checking in.

Comment 13

[Pete Zha]

Attachment: patch which I want to check in with bienvenu's comments

Comment 14

[David :Bienvenu]

that's fine, you don't need another round of reviews.

Comment 15

[Pete Zha]

thanks:)
checked in

Comment 16

[esther]

Uisng trunk builds 20021121 on winxp, linux and macosx, This is fixed on linux
and winxp but I don't see the fix in Mac OSX.  

Comment 17

[Pete Zha]

This is a cross platform bug. I don't see why this doesn't work on Mac OSX...

Comment 18

[Ninoschka Baca]

Trunk build 2003-02-05: Mac 10.1.
Trunk bild 2003-02-05: WinMe
It appears to be working for me using the above builds. Esther, how does this
work on your Mac system?

Comment 19

[esther]

Ninoschka and I both checked into this and found that it works on the MACO trunk
builds but not the MAC OSX trunk builds.  

Comment 20

[Rafael Ebron (:rebron)]

Mail Triage: nsbeta1-

Comment 21

[Karsten Düsterloh]

This is WFM with Mozilla 1.7.7 and current nightlies, both on Mac OS 10.4.

Comment 22

[Jason Bassford]

No specific bug / patch referenced as the fix for MacOS 10.

-> WORKSFORME