Platform: PowerBook G3/300/192Mb/25Gb, MacOS X 10.0.4 Fizzilla Build: 2001071305 1) Launch Moz. 2) Goto Tasks: Mail. 3) Click a message in your inbox to view it. 4) Click the Reply button. The new window displays with, "<name> wrote:" followed by the quoted text with no <CR> between. Please add a <CR> between the "wrote:" line and the quoted text. Not sure how bug 70842 and this one fit together, if they do at all. I'm listing this under MacOS X, but I believe this is all/all. - Adam

That a newline is inserted between "wrote:" and quotation had been a bug and was fixed several days before. See bug 67391 and bug 69638. This should be marked as invalid.

I don't agree. Bug 67391 discusses Moz adding multiple newlines all over the message. I'm talking about adding one specific one, just under the <name> wrote: line. My requested behavior is common in every email client I've ever used. Bug 69638 doesn't appear to have anything to do with this. - Adam

Koike, After reviewing bug 67391 in detail, I see where you believe you fixed your problem. However, not all newlines are bad. A newline after the "wrote:" line is common; it appears you object to having MULTIPLE newlines added to a message everytime a reply is done. Here's my thinking on this. Let's say we have the following email exchange. I'll use brackets to denote begin and end of the email. First, an email from you to me. [Hello!] Now let's say you sent that to me, and I hit reply in my email client. My expectation is that my email client adds the following: [KOIKE wrote: > Hello! Hey there KOIKE! - Adam] Now I send that to you, and you reply to me. [Adam wrote: >KOIKE wrote: >> Hello! > > Hey there KOIKE! - Adam So long for now! *KOIKE*] I guess the first question is, do you agree with me that the above interchange is correct? - Adam

Before the patch for bug 69638 was checked in, a newline is inserted between "wrote:" and quotation. As far as I know, there is no mail client which insert a newline. Outlook Express doesn't work as such. Why do you think a newline should be inserted?

I have read the entire text of bug 69638, and I still don't see how it pertains to this bug. It's interesting, tho, and a problem on OS X... I think a newline should be inserted because it gives the recipient's eye a quick way to gloss over text that the email software added, and where quoted text or the response starts from the sender. When everything is glommed together, it might be more efficient in bytes sent, but it is ugly. Perhaps worse, if you have two Mozilla-using users going back and forth in replies, with your way you get: [Adam Masri wrote: >KOIKE Kazuhiko wrote: >>Adam Masri wrote: >>>KOIKE Kazuhiko wrote: >>> >>> Hey Adam, I think you're wrong! >>No Koike, I'm always right. >Who says?] Sorry, but IMO carriage returns make this exchange easier to read. They serve as visual indicators to the eye where one person stopped talking and the other started. This situation gets even worse when people are using different email clients; some clients make mistakes as to where to place spaces & quote marks. You soon get lines that look like > >> > > Hey there! > > >>>> Hey! Apple's built in Mail client works this way in OS X. Claris Emailer v2 works this way in MacOS. Netscape Communicator 4.7 works this way. I don't know how many examples you were looking for... - Adam

Please make a distiction between newline/CR and an empty line. An empty line means *2* newlines. No newline woule mena that you see: <1> Ben Bucksch wrote: > This is what you reply to. I'll type a bit more, so you > can see some wrapping. </1> Of course, *that* would be a bad bug. Now, if you get: <2> Ben Bucksch wrote: > This is what you reply to. I'll type a bit more, so you can see some wrapping.</2> or if you get: <3> Ben Bucksch wrote: > This is what you reply to. I'll type a bit more, so you can see some wrapping.</3> then I'd argue that there's no bug. It is completely argueable, if the 2. or 3. layout os better. Personally, I prefer the second. Am I right in the interpretation, that you see 2, but ask for 3? Then, this is IMO not a bug, but still a valid request. Ne need to decide, what we want. In any case, there must be an empty kline between the quoted text and the erply our user types. So, the example Adam Masn shows above is a bug, but for other reason than stated here. I.e. it should look like [>>> Hey Adam, I think you're wrong! >>No Koike, I'm always right. >Who says?]

>Please make a distiction between newline/CR and an empty line. There's a difference? In my vocabulary, <CR>, ASCII 13, and newline mean the same thing. Could you please explain what the difference is? In the examples, I'm enclosing the message within brackets for clarity of begin & end. They are not part of the message. Currently, when I hit reply, I get: [Ben Bucksch wrote: > Please make a distinction...] What I'm asking for is: [Ben Bucksch wrote: > Please make a distinction...] It sounds like I'm asking for behavior #3. IMO, this is a bug, because every email client I've ever used on every platform I've worked on has worked that way, and it is the way Communicator 4.7 works. - Adam

Back to ducarroz (bugzilla glitched and didn't take my change with the last comment).

Not Mac OS X specific

Simon, Please re-read this bug. I do not know which platforms this is NOT all/all for, but if you read Koike's linked bugs, and our thread here, obviously he doesn't think this is all/all. Even tho I do... - Adam

Communicator 4 does put a line in, but prepends it with a ">" like: [Ben Bucksch wrote: > > Please make a distinction...] ... which is an action that's aggravated me for years. I've always cut the extra line out. Maybe make this a preference?

I also found the blank "> " line annoying and edited it out.

comment 6: > Personally, I prefer the second. That was ambiguous. My favourite would be WONTFIX.

I agree with the original reporter - in fact, I was going to file this RFE myself (and found that it's already in Bugzilla). The way it currently works is IMHO ugly and I always end up just inserting this newline by hands. In case it is decided that we want to keep people who do not want such an empty line (Ben, for example) happy, then please consider this as an RFE for adding a preference for such an empty line. Of course, just making the whole "...wrote" text customizable would work as well.

I'm getting XXX wrote: original text starts here instead of XXX wrote: original text starts here Just a little thing, but it's driving me crazy..

Which build are you using? I think I fix that problem recently.

WFM for a long time. pi

Still a problem with BuildID 2003012513 compiled on Red Hat Linux 8.0 running on Red Hat Linux 8.0.93, plaintext compose.

Maybe I get this bug wrong. When I hit reply, the mail starts with the attribution line, then an empty line and then the first line of quoting. Well, this is probably because I have the following in my user.js: // Intro line user_pref("mailnews.reply_header_colon", ":<br>"); So I guess, this bug is WFM. Or do you want the default to be changed? pi

Does that pref work with plain text compose?

Absolutely. I always forget that there is something else than plain text compose. It sounds so absurd to me ... pi

Ah, user_pref("mailnews.reply_header_colon", ":<br>"); does work! I still think it should be a default, or a t least there should be a UI for it.

In order to work properly when you have the pref set to start the reply above the citation, I have found that I need to add a &nbsp to the string: user_pref("mailnews.reply_header_colon", ":<br>&nbsp"); Otherwise, an intermittent problem occurs where the editor appears to lose the end-of-file marker.

Exactly. I think my description should be default, or at least there should be a UI pref for it. I think it was working properly before Koike's bug was fixed. - Adam

I noticed while looking into this bug that the *first* time after Mozilla starts up that you hit Reply, the quoted text immediately follows (on the next line) the "wrote..." attribution line. (Plain text composition, that is.) The second and subsequent times you hit Reply, there is a blank line between. This is with Mozilla 1.4 Final and with a 1.5b, under Win2K. I have a simple ":" for the preference mentioned in this bug. Does this match others' observations?

The symptom I described in comment 25 was reported as bug 211768.

Now that bug 144998 has been fixed, I am not seeing any cases where the blank line is left between the header and the quoted text (in plain text). I also see (I don't think this is related) that the "<br>" text appears verbatim at the end of the header.

(In reply to comment #27) > I also see (I don't think this is related) that the "<br>" text appears > verbatim at the end of the header. xref bug 226508. It was suggested to me via email that '\n' will do the trick, but: no, it doesn't.

(In reply to comment #28) > It was suggested to me via email that '\n' will do the trick, > but: no, it doesn't. I just had occasion to test this again. '\n' *will* work if you edit the prefs.js file to put it in. If you enter it via the Config Editor (about:config), that escapes the \ and ends up with the predictable result. I'm guessing that's what I tried before.

Discussed this with Bryan, and this would be great to have this functionality and pref tweak delivered via an extension. But for the mainstream experience, this is wontfix