Open Bug 161968 Opened 22 years ago Updated 2 years ago

Breaking quoted line with typed CR loses quote status for end of line

Categories

(MailNews Core :: Composition, defect)

defect

Tracking

(Not tracked)

People

(Reporter: 3.14, Unassigned)

References

(Blocks 3 open bugs)

Details

Spinoff from bug 133741, comment 12.

When in the middle of a quoted line you hit enter, both parts are blue. The
second part will not be mailed as a quote, though. You have to manually enter
the quote symbol >.

pi
Steps- seen in trunk builds 20021119 on winxp, mac and linux.
1. Set your account to compose in plain text. (uncheck the html option in
account settings)
2. Open a plain or html text message and click reply, you will see the quoted
text in the default color of blue as well as the quote symbol ">".  
3. Place your cursor in the middle of the line of quoted text and hit <Enter>
then type in the word "break".

Result: "break"is black text as expected but the blue quoted text after the
<Enter> action is wrapped to the line after the break line and is still blue but
missing the quote symbol and is not sent as quoted.
Expected:  the wrapped quoted text to stay quoted 


workaround: Place a ">" before the blue non quoted text that wrapped to the next
line to have it received as quoted text after sending.
I wonder if it would actually be reasonable to insert a "> " in this case.  Joe,
how hard would it be for the edit rules to do that when splitting a plaintext
quote in the middle of a line?
I really don't want to go there.  Plain text is supposed to be like plain text.
 Inserting characters is not what I would expect from plaintext mail.

The bug is that the quote formatting at send time is being based on ">", rather
than the mailcites.  I'm sure someone will tell me it's some goofy standard. 
It's still not a good thing to do.
> The bug is that the quote formatting at send time is being based on ">", rather
> than the mailcites.

Not really - the thing is that it is based on *both*. The plaintext editor has
an internal state that knows for each line whether it's a mailcite line
(displayed blue) or a new content (displayed black). The line would be sent as a
quotation line if it *both* is a malicite line *and* starts with a ">"!

The thing is - in blue (mailcite) lines, the ">" does not really stand for the
symbol ">", it's just a text representation of the blockquote black bar (that
used to be there even in plaintext composition).

IMHO there is nothing wring with inserting ">" - many plaintext editors insert
things for people (autoindenting, etc).
I like Akkana's idea. When I press return in the middle of a quoted line this
happens, because I want to put some comment right there. The rest should still
be quoted for further comments later. So far I alway add the "> " manually.

Without a quoting simple (recall that we talk plain text here) it does not make
sense to have some line have the status "quoted". Generic news readers (like
Forte Agent) only look at the quote symbol, by just adding it you got quotes.
This is (for plain text) the most reasonable way. It might be hard to get this
in Mozilla, though.

pi
On second thought, I think mozilla-bugs@nogin.org and I are both totally off
base.  This is plaintext mail, so it's being sent as just text?  So there is no
opportunity to identify quotes at send time, because only plaintext is going
out.  Whether something is a quote or not is just up to the client on the other end.

Typically those clients will identify leading ">" on a line as a quoted line.

So there are really two issues here.  
1) Will the text you are editing be wrapped or not when composing.
2) Will the line you are editing be identified as a quote.

The way to asnwer 1) is to ask "is it blue".
The way to answer 2) is to ask "what is my recipients mail client going to think".

It's understandable that users would like both answers to be always the same,
but I think it's time better spent elsewhere. 
> This is plaintext mail, so it's being sent as just text?

No! It is being sent as "format=flowed" where it is well-defined (by RFC) what
is a quote and what is just a ">" symbol. If you add a ">" in the beginning on a
black line, it gets sent as just the ">" symbol. If you prepend a quote to the
blue line, it gets sent as a quote.
Is our serialzer doing space stuffing for ">" lines based on whether the source
has a mailcite node around it?  I took a look at nsPlainTextSerializer.cpp, and
I see some code that looks for the flag OutputFormatFlowed and does different
things based on mCiteQuoteLevel.  But mCiteQuoteLevel is only set when inside
blockquotes with mailcite atributes (which is typical for html mail compose). 
In plaintext mail compose we use spans with a mailcite attribute.  I can't find
anything in nsPlainTextSerializer that cares whether something is in one of
these spans for purposes of Format=Flowed.

Thus I don't understand the claim that mail gets sent differently for ">" inside
the span versus outside.
Seems to WFM. Do I miss something?

pi
Long silence. Let me for a wakeup repeat the problem and suggested solutions:

Assume you reply to a message (plain text). Quotes are blue, not folded. In the
middle of a quoted line you hit enter to break it into two lines. Both lines
stay blue. Here is the problem. This coloring indicates the text is sent as
quote. Bute for plain text there is one and only one indicator that something is
quoted, namely the quote symbol.

There are two solutions here:

1) Remove the quote status of the second line. Problem: If I want to make it a
quote and add the > symbol at the beginning it might already be wrapped which is
certainly not what I want. Also see bug 114954, I am not sure, how it might
relate to this bug.

2) Akkana's suggestion to add the quote symbol automatically. This would be what
user intend. After all the want to split a quoting, but it is still a quote. If
not you can still remove the quote symbol.

So I'd go for two.

pi
Blocks: 108194
Solution 2 really doesn't get us that much further down the road.  The next
stage will be when someone asks "why doesn't the blue go away when I delete the
leading > character?".  The simple fact of the matter is that our mailcites are
html spans, and format-flowed mailcites are ">" (with whatever the correct
spacestuffing is).

The only way to make this work all the time is to have the editor examine any
changed line and decide (on a line by line basis) if the line is a quote in the
format-flowed spec.  And if it has become one, insert a cite around it; if it no
longer is, remove any cite around it.  This is a fairly significant and
expensive change.
Point taken. You are certainly right about the best solution. Akkana's
suggestion would still improve the situation. Your argument about removing the
quoting symbol remains, but this is already true now, for unchanged quotes.

pi
Re: comment 7

Actually, sending as a quote _is_ sending as a ">" symbol.  If you look at the source then 
you'll see what actually happens: a ">" at the beginning of a black line gets a space 
before it, which is truncated when viewing the message.  Though I'm not sure OTTOMH 
what happens when such a line is replied to.
Blocks: 168420
Lets suppose I'm replying to a mail in plain text ("|" marks the cursor location):

> Asdf qwer zxcv. |Uiop jkll
> rewq fdsa. Vcxz poiu llkj

When pressin enter before word Uiop I exect (and edit manually currently) the
text to look like this when starting to write a reply:

> Asdf qwer zxcv. 

|

> Uiop jkll rewq fdsa. Vcxz
> poiu llkj

What it does is enter two \n before the cursor, two \n after and adds "> " to
next paragraph. Also it would be handy if rewrap is applied to then next
paragraph automatically after the split.

IIRC KMail works like this currently (optionally?), KDE-CVS-Digest mentioned it
sometime last year if I'm not mistaken, but can't find the bug nor digest entry.
Updating the summary; this really isn't a "wrap" issue.

I find the issue raised in Joe Francis's comment 11 to be sort of moot.  I don't 
see much of a need for "removing quote status" -- for the vast majority of 
editing-the-quote situations, this is simply not an issue.  Even for the cases 
where it is an issue, the current behavior is broken now.

Adding the quote character on breaking the line -- as described in comment 2 and 
reiterated in comment 14 -- fixes a particular issue that people frequently 
encounter and doesn't make the other, far less frequent one any worse.

I would suggest that the quote level be maintained -- if the line being broken 
is preceded with  >>>  then that's what should be inserted; otherwise, we're 
back to manually having to tweak it.
Summary: Wrapping quoted lines get wrong quote status → Breaking quoted line with typed CR loses quote status for end of line
Blocks: 223983
*** Bug 224928 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
I think this bug is really about the problems that occur when you reply
to a message, and the choose to break a quoted line apart, by typing 
"enter" at a point in the middle of a quoted line.  Yes?

As noted, no ">" is placed at the beginning of the newly broken line.
I don't think that is the problem, really.  The problem is that the user
cannot place the missing ">" at the beginning of the line and have it 
be treated as a quote thereafter.  

Apparently, if the user types a ">" at the beginning of the line, some
code somewhere inserts a blank in front of it (perhaps as it is being sent).
When a mozilla/TB user receives that message, he sees the vertical bar 
for some of the quoted lines, and sees a " >" for the line you broke.  
e.g. 

Desired result:  recipient sees:

| original quoted line number 1
| original quoted (broken here)
my comment
| line 2
| original quoted line number 3

Actual result:

| original quoted line number 1
| original quoted (broken here)
my comment
 > line 2
| original quoted line number 3

which looks horrid because it is inconsistent.  All quoted lines 
appearing with vertical bars, OR all quoted lines beginning with ">"
would be OK, the mixture of the two is horrid.

To work around this, I typically type "ctrl-A  ctrl-X  ctrl-V"
which then makes all quoted lines appear to begin with " >".
Having to do this is most annoying.

I really wish this wasn't necessary.
I really wish that all lines that begin with > in the plain text 
composer appeared the same, regardless of whether the ">" was put 
there by me or by the reply quoter.  

I think this comment is merely a restatement of this bug.  
If you think this is a separate bug, please advise.  
> As noted, no ">" is placed at the beginning of the newly broken line.
> I don't think that is the problem, really.  The problem is that the user
> cannot place the missing ">" at the beginning of the line and have it 
> be treated as a quote thereafter.  

Boris P. has stated the same thing in the past, but I have no problem with 
making this work.  What I do is make sure I type the '>' while at the beginning 
of the second part of the line, rather than typing '>' on a blank line and then 
<del> to append the second part of the quote line.  The clue to whether this is 
working correctly is whether the '>' is shown in blue or black -- if it's blue, 
the line will be treated as a quote.

This always works for me (Moz and TB, Windows 2000), and I don't understand why 
it's a problem for other people; maybe it's a Linux thing?


> I really wish that all lines that begin with > in the plain text 
> composer appeared the same, regardless of whether the ">" was put 
> there by me or by the reply quoter.  

You can get that effect by turning off format=flowed, but personally I find the 
advantages of f=f, even with the several bugs in Mozilla's implementation, to be 
far more beneficial than the problem of loss of quote.
*** Bug 339706 has been marked as a duplicate of this bug. ***
(In reply to comment #19)
> *** Bug 339706 has been marked as a duplicate of this bug. ***

Copy&paste for last comment from bug 339706:

     Yes, there is duplication. Bug 161968 even more generic, because there
proposed to automatically insert four breaks and place cursor in middle. But my
proposal is more generic in other aspect, because I concern more generic
quotation prefixes. See also bug 339704.
Assignee: ducarroz → nobody
QA Contact: esther → composition
Product: Core → MailNews Core
Confirmed to persist in TB 3.0 (on OS X 10.6). This forum post is related: http://forums.mozillazine.org/viewtopic.php?f=30&t=261156
1) A workaround for this problem: Place a ">" at the correct position in the quote, and /after/ that do the line break (directly before your >). Then the quote is correct. If you first break a quote and then type a >, this > character is interpreted as an intentioned character by silently adding a space before, as mentioned above; although the whole line is marked blue, it is not interpreted as a quote.
2) I hope you are not angry with me, but: It’s very disappointing (almost disturbing) to see that such a tiny bug is not repaired in 13 years. Although I do not have the right to demand anything, you should eliminate such problems. Please repair this bug, it would be a great favour.

I suggest the obvious change to automatically add a > at the beginning of the second line after hitting enter in a quote. I further suggest to copy the behaviour of Evolution, where the user cannot move the cursor to the quote signs (but I think he can delete them with backspace). This way the difference between a “real” quote and a user-typed > sign can easily be seen.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.