Open Bug 114954 Opened 23 years ago Updated 2 years ago

Mail editor space-stuffs quote prefixes in pasted text

Categories

(MailNews Core :: Composition, defect, P3)

Product:
MailNews Core
Component:
Composition
Type:
defect

Tracking

(Not tracked)

Milestone:
Future

People

(Reporter: andy, Unassigned)

References

(Blocks 1 open bug)

Details

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120
BuildID:    20011112012

I am in the habit of composing long emails in a different editor, and then
pasting them into the Mozilla editor before sending.  Unfortunately, Mozilla
misinterprets the "> " quote prefix at the beginning of lines as *not* being a
quote, and inserts a space before the beginning of the line.  Mail clients that
interpret quote prefixes for format=flowed content will therefore render the
mail incorrectly. Specifically, mutt's colorization feature doesn't work.

If pasted or typed text matches the approproate quote prefix, Mozilla must not
"reinterpret" what the user told it.  Pasted text should be *literal* text; why
else would I bother to paste it?

Alternative solutions:

+ Provide (and document) a method for turning off format=flowed in mail sent
from the Mozilla mail editor.

+ Provide a way to invoke an external editor.  This would be my favorite,
although I suspect the NIH factor will prevent this from making it into the
official tree.

Reproducible: Always
Steps to Reproduce:
Write an email containing "> " at the beginning of quoted lines in an external
editor.

Paste into the Mozilla mail editor.

Send.

Actual Results:  What comes out on the other side is not what was pasted.  There
are spaces before the ">" characters.

Expected Results:  No inserted spaces before the ">" characters in pasted text.
Confirming on 2001121703, Win95, following suggested steps. It is easy to see
that blank leading character in View->Message Source->Select All. 
Marking as new, OS->All.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
->Editor:Core
Assignee: sspitzer → kin
Component: Mail Window Front End → Editor: Core
Product: MailNews → Browser
QA Contact: esther → sujay
format=flowed shouldn't have anything to do with this, since it takes effect at
save time, not at paste time.  We shouldn't be adding spaces at the beginning of
lines on paste whether or not the line starts with >.  I wonder where the spaces
are coming from?

Is this bug on plaintext mail compose, or html mail compose?  The description
doesn't say.
Not sure about the reporter but plain text for myself.
My problem was with the plain text mail composer, but I just verified
(against 0.9.7) that the HTML composer has the same behavior.

The format=flowed note had more to do with the client end.  According
to the RFC (about which I am *not* an expert), compliant mail readers
are supposed to treat lines beginning with the "> " quote prefix
specially, by doing whatever magic they want to make the quote appear
quote-like.  Lines that are supposed to begin with a literal "> " are
escaped by adding a space at the beginning.

My supposition was that the Mozilla developer decided that a user that
*typed* a "> " at the beginning of the line wanted the literal text,
and not a quote.  While this sort of makes sense in a philosophical
sense, it breaks the common case of a user pasting quoted text into
the mailer.

I don't believe the paste operation is part of the problem; I
mentioned special-casing it as a compromise in case the response was
"this is not a bug". :)
I wonder if it's possible that it's pasting html and treating the entity ">"
as not being the same as ">"?  (I still don't see why it would prepend a space,
though.)  But that doesn't seem likely if the copied text is coming from an
external text editor.
Target Milestone: --- → mozilla1.2
Blocks: 133741
Blocks: 110949
There is just one more thing to this bug. As the reporter said, in format
flawed;-) a whitespace appears before the pasted quote symbol. This is not true
in the plain text editor when f=f is turned off, those pasted or just typed
lines are not recognized as quotes by the editor, though. You see, that they are
folded if they are to long.

pi
Cc'ing Daniel: this is another example where space-stuffing is causing quoted
text to be unquoted, even without the fix to bug 134439.
Yes, f=f rquires us to space stuff any line beginning with a '>' that we don't
_know_ is a quote. We can never _know_ that a line beginning with a '>' is a
quote. That's why f=f requires blockquotes and the editor to work really well. 

This has anything to do with pasted text. Anything the user writes or pastes are
treated the same.

What I would like to do is to recognize that the mail contains no flow, that
it's prequoted and prewrapped, and then turn off f=f since the mail author
already made it impossible to benefit from f=f. I don't think that would be easy
though. In the best case it would probably require the serializer to run two times.

Btw, has anyone contacted the mutt's authors and heard if they might be able to
fix this in their end? Most (mutt was the first I heard of) readers seems to
cope just fine with the inserted space.

>Yes, f=f rquires us to space stuff any line beginning with a '>' that we don't
>_know_ is a quote. We can never _know_ that a line beginning with a '>' is a
>quote. That's why f=f requires blockquotes and the editor to work really well. 

I think it should be the other way round. By default, a > at the beginning of a
line should be treated as quotes. This is what people use to mark quotes. I did
that above. Another exampe is, that the quotes are manually cut from one line
into two to add comments like this:

> This is one sentence. Here another

Becomes:

> This is one sentence.

Reader's comment goes here.

> Here another
~ enter manually

More reader's comment here.

This is broken by current behavior. It is another example of a program trying to
know better what the users means.

pi
It's not "broken". You will still get the quote chars on the other side. The
only issue seems to be that mutt doesn't color hand written quotes sent from
Mozilla. (It would work if you pasted your text into a blockquote in the
formatting editor instead of adding '>' yourself in the plain text editor)

You're also contradicting yourself. First you say that Mozilla should discover
quotes and understand what the user means (which is impossible from the written
text). Then you say that Mozilla shouldn't be smart and do things for the user.
You obviously want Mozilla to do what _you_ want without having to tell it, but
other users have different needs. 

I, for instance, when I studied maths often wrote mails with lots of '>' as part
of expressions. I wouldn't like to have them misinterpreted as quotes just
because they are used as quote chars too.

Anyway, the space stuffing is part of format=flowed. If you don't like it, you
can disable format=flowed sending. Changing the default in Mozilla would require
turning off f=f which I don't think we want to do. What we could do is making it
turned off in cases where we have no use of it (no lines longer than 70 chars,
no blockquotes), but I don't know how to detect that without causing a
performance hit.
Blocks: 108194
Sigh.  I was really afraid of this "not a bug" response.  Which is why
I suggested this in the original report:

+ Provide (and document) a method for turning off format=flowed in
  mail sent from the Mozilla mail editor.

Happily, it looks like it *can* be turned off.  How?  Will this stop
the silent munging of my input data?

The bottom line, to reiterate, is that Mozilla's mail editor behaves
very badly when the user composes quoted text in an external editor.
Blaming mutt, which is interpreting the RFC correctly and not
colorizing the space-prefixed quotes, seems like bad form to me.

If the decision is that format=flowed is incompatible with external
editors, then that's fine.  But there needs to be a fallback or
workaround for those circumstances.
I see it over and over again. People just assume that they will send what they
see (and this is a very reasonable assumption).

Andy, you can get rid of format flawed:
http://www.hmetzger.de/net6e.html#10

pi
The point of format=flowed is to be correct, not to guess. Assuming that lines
starting with > are quotes is a guess, because they might not be.

We (Daniel, akk and me) discussed this or a very related issue in another bug,
but I don't remember which one it was.
Summary: Mail editor misinterprets quote prefixes in pasted text → Mail editor space-stuffs quote prefixes in pasted text
That's just pedantic nonsense.  The editor cannot possibly know what
the intent of the user was, so any interpretation if makes of a quote
prefix is, by definition, a guess.  Given a choice between "guessing"
that the prefix means what it has *always* meant (for 20 years!) or
the meaning handed down by a poorly understood and poorly implemented
(and widely loathed, c.f. format=flawed) RFC, you appear to have made
the wrong choice.

There is a real world (!) Use Case here of why mangling quote prefixes
is a bad thing.  It causes RFC compliant mail readers like Mutt to
misinterpret quotes pasted in from an external editor as literal "> "
prefixes.  What can the possible real world reasoning be behind the
mangling?  Have you ever seen a literal ">" at the beginning of a mail
line that wasn't a quote?  Ever?

I'm happy with the "turn off format=flowed" option as the answer here
(although I dearly wish it were available in the GUI).  I just boggle
at the lack of respect among the developers here for obscure
technologies such as "cut-n-paste".  Let me rephrase your responses in
a less charitable manner:

  Mozilla doesn't support cut and paste of quoted text into the mail
  reader.  If you didn't type it here, it's wrong and won't display
  reliably.

Does that sound as dumb to you as it does to me?

I fully agree with Andy. People do not understand what you call correct, Ben. So
there are two possible solutions:

1) If people enter a quote character, i.e. >, let it be a quote.

2) If you don't want to allow people to enter quote characters, make it
absolutely clear in the editor, that this is not a quote character, i.e. either
do not allow entering one at the beginning of the line or add a space already
there, clearly visible.

I bet, that as soon as 2) is implemented we get a new bug for the "most
frequently reported" list.

pi
 > There is a real world (!) Use Case here of why mangling quote prefixes
 > is a bad thing.  It causes RFC compliant mail readers like Mutt to
 > misinterpret quotes pasted in from an external editor as literal "> "
 > prefixes.  

So what RFC says that a "quoted" line must begin with a > and mustn't contain
any whitespace before the '>'. At the contrary, RFC 2616 forbids us to send > at
the start of the line if we doesn't _know_ that it's part of a quoted paragraph.
I know I've said it before, but I'll say it again. You're putting things out of
their perspective. 

All this about breaking display, that is really about a bug in mutt not
understanding that a line starting with " >" is a quote. Have you ever seen a
line that starts " >" that isn't a quote? Isn't that a bug in mutt? 

The mails look fine to me in Netscape 4, Mozilla, Outlook, OE, Eudore, less,
pine, gnus and Pegasus. I haven't got any other mail programs to check with but
I think it covers somewhere about 99% of all mail users.

You say pasting into Mozilla is broken, but you can paste text into Mozilla and
you can send the mail and the receiver can read all the text with the quote
chars in front. So what else beside mutt's coloring isn't "working" as you would
like it to? Everything you say suggest that it's a bug in mutt's AI - where mutt
decides how to color lines.

 > What can the possible real world reasoning be behind the
 > mangling?  Have you ever seen a literal ">" at the beginning of a mail
 > line that wasn't a quote?  Ever?

Yes. Not often but it happens.

Let's as an experiment think about what would happen if this was fixed as you
would like it to be fixed. Then every line starting with a ">" would have to be
marked as a quoted paragraph. That seems fine, but what if the receiver decides
to display each quoted paragraph a vertical margin? Then you would get a very
sparse text and that would be much worse than "no coloring in mutt". 
In this case you're tricking the sender because the marking says "This is a
quoted paragraph". Right now we just produce quotes that mutt's not well written
enough to understand. 

A second solution would be to disable format=flowed when someone enters a "> at
the beginning of the line, but wouldn't that be magic? How should a user know
why it sometimes send f=f and sometimes don't. A program must be predictable.
That could be an option anyway if it turns out that there really are some issues
with the current handling, and I don't want to hear about mutt's coloring any
more. Take that with mutt's author, not us.

A third solution would be to detect quoted paragraphs and do automatic
(implicit) rewrap. Don't take us there.
> All this about breaking display, that is really about a bug in mutt
> not understanding that a line starting with " >" is a quote. Have you
> ever seen a line that starts " >" that isn't a quote? Isn't that a bug
> in mutt?

 > The mails look fine to me in Netscape 4, Mozilla, Outlook, OE,
 > Eudore, less, pine, gnus and Pegasus. I haven't got any other mail
 > programs to check with but I think it covers somewhere about 99% of
 > all mail users.

This is patently false.  Mozilla's reader has exactly the same
behavior.  Send a message that contains a quote prefixed by " >" and
read it.  It doesn't look like a quote, because the RFC promises that
it is not a quote.

Why doesn't it look like a quote?  Because the editor space-stuffed
garbage into the beginning of the line to make *sure* that it didn't
look like a quote.  Why did the editor do this?  Because the editor
thought it was smarter than the user about what a quote was.  I'll
take users over editors in a brain war any day of the week.

> You say pasting into Mozilla is broken, but you can paste text into
> Mozilla and you can send the mail and the receiver can read all the
> text with the quote chars in front. So what else beside mutt's
> coloring isn't "working" as you would like it to?

And here we come to the real issue.  It's not a bug, because you don't
find it important (note the telltale use of the quoted "working" to
indicate your disdain for the issue).  I do; I've had several people
complain (to me, not to you) that my mail is bad because the quotes
don't colorize like they do from every other mail editor in the world.

I've carefully formatted this message to have the same brain damage.
Snip it out, and send it verbatim (via a command line sendmail or
somesuch).  Note that the first paragraph above is a quote (and
remains a quote when you reply).  The second is not, and displays
verbatim ">" characters when you reply.

> Let's as an experiment think about what would happen if this was
> fixed as you would like it to be fixed. Then every line starting
> with a ">" would have to be marked as a quoted paragraph.

Again, untrue.  You haven't read the RFC carefully enough.  Successive
lines beginning with the quote prefix are treated as part of the
*same* paragraph, not different ones.  The only way to get the
behavior you posit would be to stuff extra line endings in.

> Right now we just produce quotes that mutt's not well written enough
> to understand.

Or Mozilla.  Maybe we should just chuck all these broken mail readers
and go with outlook. :)

Ah, you use the auto-detection of quotes that Ben wrote for Mozilla? I don't and
that's why I not see the difference. I apologize for my memory lapse about the
standard and paragraphs, but my point still stands.

> 2) If you don't want to allow people to enter quote characters, make it
> absolutely clear in the editor, that this is not a quote character,

I may get pilloried for this, but it's sounding more and more to me like we
should consider the option of showing quotes in plaintext mail with the "blue
bar" when f=f is being used.  If lines beginning with > aren't going to be sent
as real quotes (i.e. lines beginning with >) then we're doing the user a
disservice by displaying real quoted lines (lines sandwiched in a quote span,
which will not be space stuffed) the same as other lines that currently begin
with > but will eventually be space-stuffed.  I know many plaintext mail users
hate the blue bar; but the reason they hate it is that it indicates that
"something different" is going to be done to the message before it's sent (that
it will be sent as something other than what they see in their compose window),
so in this case we'd be only being honest.

jfrancis' CSS patch to bug 83378 will do a bit along these lines: "real" quotes
(which won't be space stuffed) will be shown in plaintext compose as blue (but
still show >, not the blue bar).   (It will do this always, not only when f=f is
on.)

Daniel:
> The mails look fine to me in Netscape 4, Mozilla, Outlook, OE, Eudore, less,
> pine, gnus and Pegasus. 

"Fine" meaning all the quotes were shown as quotes, not just as space-stuffed
unquoted lines beginning with >?  Were you using the default settings on these
mailers?  I would have guessed that most of these mailers would do quote
detection and show quoted text differently (I'm sure nearly all of them have
that option).  Didn't Netscape 4 show quotes as blue and italic by default? 
Pine doesn't colorize them by default, and neither does mutt, but it's easy to
enable the behavior.  It would be interesting to have stats on which mailers
highlight quotes by default.
> "Fine" meaning all the quotes were shown as quotes, not just as space-stuffed
> unquoted lines beginning with >? 

I just meant that I saw the text as quoted text, not mangled in any way. There
might be extra formatting for quotes that weren't applied, but in that case I
didn't notice it. Maybe I'm just not having as I high requirements on the
display as some.
*** Bug 134341 has been marked as a duplicate of this bug. ***
I'm not sure, if this is the same bug, but I see this "space-adding" in more
places (I _only_ use the plain-text editor):

1. I have a signature, that looks like this:
/"\   ASCII RIBBON              PS2-Assistent
\ /     CAMPAIGN
 X    AGAINST HTML     Jan Schnackenberg: snb@fh-wedel.de
/ \ IN MAIL AND NEWS

   Unfortunately Mozilla always adds a space before the "X" in the 3. line. 
   If I view a message send by me in mozilla everything looks fine. In every
   other browser the 3. line is indented by one space.
   (Mozilla-users can see the space by displaying the message-code)

2. If I compose a message, which is formated into a table-like structure,
   and save that message as a draft or template, after reopening the 
   message I see that every line, that started with a space, is indentet
   by one more space.

Additionally I want to mention, that the behavior described by "pi" in comment
#10 makes editing replies a real pain for me. And I do editing like that a lot
(or I would do it, if it would work).

I'm not sure, if there _is_ a RFC that describes how a quote in an
e-mail/newsposting should look, but if I type an ">" at the beginning of a line,
I _expect_ that that char stays exactly there without any spaces added before
it. (Just like I don't expect the spaces that are added in the above mentioned
cases) If that line is "wrongly" colored/highlighted as a qoted line in any
other readers, that is _my_ (read the mail-writers) fault. But if Mozilla adds
additional characters (without showing them in the editor) I  don't even have
the chance to "correct" it's missconception about knowing better than I do.
Akkana, you say:

[the following quotes hand-marked, would not work wit f=f;-)]
> I may get pilloried for this, but it's sounding more and more to me like we
> should consider the option of showing quotes in plaintext mail with the
> "blue bar" when f=f is being used.

I agree, that would do it. This (or similar) is in bug 133741, which is already
marked as blocked by this bug.

pi
jan wrote:
> Additionally I want to mention, that [this] makes editing replies a real pain
> for me. And I do editing like that a lot (or I would do it, if it would work).

Are you saying that you cannot edit quotes (e.g. replace parts of sentences with
"...") (with the quote still being recognized as that)?

This would indeed be very broken, but that's *not* this bug. It would e.g. be
solved by akk's suggestion of using blue bars (which I think would be a good
idea, if the blue bars didn't have that "HTML taste" and would thus alienate
plaintext composer users), which still leaves this bug open - you'd still be
unable to manually insert ">" as quote marks at arbitary places.


Jan, what you are critizing with the doubled spaces is format=flowed, not
Mozilla's implementation (I think).

> I _expect_ that that char stays exactly there without any spaces added before
> it.

I guess we have some clash of POVs here. You want to compose the msg as it will
be sent *on the wire*. I am not sure that's possible or a good idea.

IMO, you cannot express all which (even plaintect composer) users want to
express with the 7bit US-ASCII or at best 8bit Latin-1 characters that we are
restricted to in plaintext on the wire. As soon as we need to exceed that, e.g.
- compose Japanese mails
- add rare characters
- make the msg readable on anything else that 80-char-wide displays
- reliably mark quotes
we have to use some additional encoding standard. That encoding will often
(sometimes necessarily) break the assumption that one typed character equals one
byte in the msg on the wire.
Now, if both the sending and the recieving mailer support the same encoding
standard *and* the standard is designed to be non-altering (i.e. input=output -
not sure, what the right term for that is), only then can you assume that the
recipient will see the same that you see. That is, unless the standard (probably
intentionally) leaves the implementor or user on the recieving side freedom to
display the msg as he likes, within some limits - in the case of format=flowed,
the line-width is a preference of the recipient.
But, if the recipient doesn't support the same encoding, then you do not see the
same that you composed. That's the problem you hit here and why Jan's sig looks
correct in Mozilla, but not in some other mailers and not in View Source.

Note that traditional plaintext mail is *not* such a non-altering standard -
there are several circumstances, where you have to "munge" (non-reversibly
change) the msg to process it further. For example, a dot on its own line
terminates the msg on SMTP (the mail transport format of the internet). Thus,
such a line, when written by a user, has to be altered to transmit the rest of
the msg. Similarily for "From " at the beginning of a msg (this time, it's
popular software that doesn't like such lines, including Sendmail (IIRC) and
Mozilla).

So, in summary, your expectation that you send - on the wire - what you wrote is
wrong, and that's not a bug, but inevitable.


Back to this bug:
I suggest to
1. assume that bug 133741 (color real quotes in plaintext composer) will be
   fixed
2. preserve the quote while editing, similar to the HTML composer. I don't know,
   how to achieve that.
3. give the user some way to insert new quotes (similar to the HTML Composer's
   Paste As Quotation)

I don't think that demanding support for external plaintext editors is
reasonable. Maybe we'll do that explicitly in the future (other RFE), but in the
meantime, I think that being able to disable format=flowed in the backend prefs
is sufficient.

Frankly, I find it surprising that you complain about missing color coding in
mutt, saying that we didn't send what you wrote, when mutt displays the mail
*exactly* as you composed it, just without the usual prettying-up. How is that a
bug worth enough to discuss that long? Or a bug at all? We have far greater
problems.
Ben wrote:
> Are you saying that you cannot edit quotes (e.g. replace parts of 
> sentences with "...") (with the quote still being recognized as that)?

Uhm, actually, that was not exactly what I was saying. Still I seem to have made
a fool out of myself there, though, because I never noticed, that the behaviour
I was wishing for (splitting a quote into 2 parts in the middle of a line, with
the second part being recognised as a quote after prepending a ">" to its first
line) is now working. Sorry.

Aside from that Ben gave me something to chew on (read: think about). Thanks for
some clarification about some cases where the code of "plaintext" messages has
to be altered. 

Just one question remains:
I'm aware of the need to "code" some Information (like the "." or the "From: "
for example) but I don't understand why there is a need to put spaces in front
of an ">". Someone has to have written the code to do that, and maybe I'm blind,
but I just cannot understand the reason for this extra work from the comments in
this bug.
The user types an ">" at the beginning of a mail, and as far as I know Mozilla
is the only MUA that prepends a " " to such a line.
The space is part of format=flowed and any RFC2646 compliant MUA add that space.
I just tested Eudora and it added the space as well. Any MUA recognizing
format=flowed also removes the space when displaying the mail so if you read
mail in one of those you might just not have noticed. 

The space is there to be able to see the difference between quoted text and text
written by the user. Some people here want to automatically convert any line
starting with a ">" to a quote when sending, but that wouldn't be very nice.

What we do need is a way to insert text as quoted. Eudora has it, both with
"Paste as quotation" and "Increase/decrease quote level".
For comment 26:

> Uhm, actually, that was not exactly what I was saying. Still I seem to have
> made a fool out of myself there, though, because I never noticed, that the
> behaviour I was wishing for (splitting a quote into 2 parts in the middle of a
> line, with the second part being recognised as a quote after prepending a ">"
> to its first line) is now working. Sorry.

Are you saying, that you enter a > at the beginning of the line and it is not
space stuffed?

pi
pi:

correct. Steps to reproduce:

- take a message in your inbox, start a reply to it and replace the 
  recipient by yourself.
- take any line inside a quoted paragraph an insert a linebreak there
- you notice that the "remainder" of the original line doesn't have
  the quotation-">"
- insert a ">" at the beginning of said "remainder"
- send the message (to yourself)
- view the message -> there is no space in front of that ">" and it
  is recognized as being "quoted"

> 3. give the user some way to insert new quotes (similar to the HTML Composer's
>    Paste As Quotation)

... which we already have, right there in the edit menu (also ctrl-middleclick
on linux).  Of course, on linux the one in the edit menu always seems to be
greyed out, but that would be a different bug (some kind of command enabling
problem in the mail compose window) which I hope is already filed.

> - take any line inside a quoted paragraph an insert a linebreak there
> - you notice that the "remainder" of the original line doesn't have
>   the quotation-">"
> - insert a ">" at the beginning of said "remainder"

That's because the block of text is already marked as a quotation since it was
the second half of a quoted block that got split.  When Joe's fix to turn quoted
text blue goes in, the difference will become more obvious.  (Hmm, Joe isn't
cc'ed on this bug; he should be.)
Priority: -- → P3
Target Milestone: mozilla1.2alpha → Future
OK, after reading this *very* long discussing I believe that I have a sequence
of steps that is more clearly a bug:

1) Start replying to a message.
2) Highlight several lines of quoted text.
3) Edit -> Cut (or Edit -> Copy)
4) Go to another place in the message (not inside quoted text)
5) Edit -> Paste
6) Send message.

Expected: pasted text is sent as quoted (is this scenario we *know* for sure
that is was quoted, no guessing necessary). 

Actual: pasted text gets "space-stuffed" quotes. If some of the original quoted
text remains, you'll see a weird-looking ugly mixture of real quotations
(displayed with a grey blockquote bar by Mozilla), with "> "-prefix quotations...

P.S. You get the same result if you cut&paste across two composition windows
instead of within the same one. This is useful if you want to respond to two
messages from a single person in one message.

P.P.S. The only workaround I know is to do "Paste as quotation" instead of
"Paste" and then  to delete on every pasted line the second ">" symbol from
resulting ">> " prefixes. I so hate having to do this every time...
Aleksey, your description is correct. There is another work-around, which is to
switch of format flawed.

pi
Aleksy, to quote from two messages, reply to one of them, then select the second
in the message list pane and choose "Options » Quote Message" in the compose
window. (I do this all the time!)
I hope the blue text for message-compose quotes is at least helping folks detect
this situation, and helping them remember to paste as quotation when that's what
they need to do.

I don't know why kin wons this bug.  Is there anything in the editor that is
doing any of this?  If so I don't know about.  I assumed it was the serializer
at copy time.
How about detecting that someone pastes text where lines start with '>'
characters and ask the user if she wants to paste the text as a quotation? It
doesn't seem very easy to me, but neither is any other "solutions".
Blocks: 168420
We need to do something. It is really annoying that cut and paste fails badly.

pi
Hardware: PC → All
*** Bug 199776 has been marked as a duplicate of this bug. ***
*** Bug 226200 has been marked as a duplicate of this bug. ***
I was going to submit a bug per the situation described in msg #31. 
Space-stuffing "> " into " >" violates POLA, the Principle of Least
Astonishment.  Let's pretend that some user wanted to use Mozilla to send mail
automatically, perhaps via copy-n-paste, or perhaps via a script of some sort:

5-sec% echo 'From: chuck
To: chuck
Subject: a test...

You called on the phone, and asked:
> Hungry?  Let's go to Maganaro's and eat...

...in order to test what would happen if you emailed back a response.

--
-Chuck
' | sendmail

One could use another MUA like /usr/bin/mail, or pine, mail-mode in Emacs, or
even a different MTA like Postfix instead of sendmail.  I don't know whether
Mozilla has a command-line "mozilla-mail" application to which one could pipe a
message into, but let's pretend it did.

mozilla-mail should behave like other MUAs in that it should add certain headers
(eg, "Date: ", "Received: ", et al), perhaps MIME content type info if needed
considering the message contents, the user's locale, and so forth.

Let's imagine looking at the results of sending that message above via all of
the various MUAs, local delivery, remote delivery, MTAs, and so forth, and then
consider what happens to the line "> Hungry?  ...".  Oddly enough, and unlike
what Mozilla does, they all refrain from mangling the "> " into " >".  Everybody
hum together now: One of these MUAs is not like the Others, One of these MUAs is
not quite the same...

Section 4.4 of RFC 2646 makes the following comparision: "(Note that
space-stuffing is similar to dot-stuffing as specified in [SMTP].)"  And indeed,
people familiar with RFC-2822 and MTAs like Sendmail or Postfix et al, know that
they provide an option as to whether or not to do so:

       -i     Ignore dots alone on lines by themselves in  incoming  messages.
              This should be set if you are reading data from a file.

[ ...or... ]

       -i     When  reading  a message from standard input, don't treat a line
              with only a . character as the end of input.

What flag does one need to use for my imaginary mozilla-mail MUA, or what
user-preference does one need to set in the real-world Mozilla application, to
not space-stuff ">" analogous to the way "sendmail -i" works?

Either that, or give me an explaination that I can satisfy a User why that User
can't send an email message with a ">" symbol in the first column of a line of text?

-- 
-Chuck

Any motion on this bug?  Have the people who think it's not a bug changed their
minds?  The issue is still present in current Mozilla and Thunderbird releases,
and I continue to have to hack my preferences every time I install or use a new
versions.
It certainly *feels* like a bug to me. I always use my own text editor to write
e-mail and newsgroup posts. So far, I've been getting around the space-stuffing
before ">" by saving the message to drafts, and then doing an "Edit as new" on
it. Maybe there could be a "Paste literal" action? "Paste as Quotation" doesn't
quite do it, because an extra ">" is added at the beginning of every pasted
line, and the composer doesn't seem to have any ability to mark (select) a
column. If the composer *must* change a ">" at the beginning of a line to " >",
at least give us an easy way to edit out the extra spaces.
*** Bug 250529 has been marked as a duplicate of this bug. ***
*** Bug 264893 has been marked as a duplicate of this bug. ***
Not an editor function, the space-stuffing happens in the sending process.
Component: Editor → MailNews: Composition
(In reply to comment #44)
> Not an editor function, the space-stuffing happens in the sending process.

In that case is there a bug report for that?  I am still unclear if I am talking
about the same bug.  I see a lot of emails generated by Thunderbird , Mozilla
(including my own emails) which quote like this:

> it hadn't occurred to me that an .xml template 
> would be in the middle of that list of users 
 > in the "contacts" folder. That looked like a list,
 > exclusively for users. Or else, I would have
> found it on my own

These quote marks were "space-stuffed" at some point - I see it mor and more as
TB is used more.

I think this is serious, but am new to bug reporting, am I on the right track here?
The best workaround right now is to turn off the sending of f=f
messages in your prefs.js file.

  user_pref("mailnews.send_plaintext_flowed", false);

I have been doing this regularly for every Mozilla/Thunderbird
installation I do for the last two years, and will probably be doing
so on my deathbed.

Folks, f=f is a disaster.  It tried to shoehorn rich-text-like
paragraph semantics onto a plain text framework in a bidirectionally
compatible way, and it failed.  It works well only in the utopian
environment where users never touch the quoted text they see in their
composer windows.  Using it by default is just dumb.

The benefit of this feature (paragraphs that wrap to the reader's
window size) is minor at best, and the cost is a very confusing and
erratic user experience, even for those who are supposed to be experts
at this stuff.  You literally need to read the RFC (or the elaborate
FAQ in bug 168420) to understand why your quotes look wrong, or why
the line wrapping is strange.  Is that really the editor experience
you want for your users?
(In reply to comment #45)

Yes, what you are showing is a classic example of Mozilla space-stuffing quoted
text.

(In reply to comment #46)
> Folks, f=f is a disaster.  It tried to shoehorn rich-text-like
> paragraph semantics onto a plain text framework in a bidirectionally
> compatible way, and it failed.  It works well only in the utopian
> environment where users never touch the quoted text they see in their
> composer windows.  Using it by default is just dumb.

format=flowed works just fine with Apple's Mail.app over in MacOS X.  Mail.app
handles pasting and editting of quoted text just fine, simply because it does
not attempt to rewrite "> " as " >".

> The benefit of this feature (paragraphs that wrap to the reader's
> window size) is minor at best, and the cost is a very confusing and
> erratic user experience, even for those who are supposed to be experts
> at this stuff.  You literally need to read the RFC (or the elaborate
> FAQ in bug 168420) to understand why your quotes look wrong, or why
> the line wrapping is strange.  Is that really the editor experience
> you want for your users?

Nope, I just want this bug fixed properly.

The rest of f=f, such as breaking up paragraphs at 76 columns for the 80-column
impaired works just fine, the only problem is with the Mozilla Mail Composer
re-formatting user-entered text.
*** Bug 252913 has been marked as a duplicate of this bug. ***
This looks to be related to bug 298485
*** Bug 298485 has been marked as a duplicate of this bug. ***
I said related , not duplicate of bug 298485.
Bug 141983 also deal with corruption done by spacestuffing.

And I would like to note that the .flf datafile in my testcase in bug 298485
have only 2 ">" qoutechars and none are at the beginning of a line , yet most of
the file have been corrupted by space-stuffing.

I can't see a logical pattern to which lines it will spacestuff and which it wont.

It is possible however that this bug , bug 298485 and bug 141983 are all just
multiple problems caused by one bug in the code.

If bug 298485 is a duplicate of this bug then it is clear that the problem is
more serious than first stated .. this doesn't just affect quotes but many other
cases as well.

This problem _needs_ fixing , you can't just say people affected by it should
use the workaround in #46 - Most people don't know of this workaround and will
switch to a working mail/news client (other clients does not foul up the
testcase in bug 298485)
*** Bug 320071 has been marked as a duplicate of this bug. ***
*** Bug 363936 has been marked as a duplicate of this bug. ***
Assignee: kinmoz → nobody
QA Contact: sujay → composition
Product: Core → MailNews Core
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.