Open Bug 161968 Opened 23 years ago Updated 8 months ago

in plain text: breaking quoted line with typed CR loses quote status for end of line because of missing ">" quote sign

Categories

(MailNews Core :: Composition, defect)

Product:
MailNews Core
Component:
Composition
Type:
defect

Tracking

(Not tracked)

People

(Reporter: 3.14, Unassigned)

References

(Blocks 3 open bugs)

Details

(Keywords: reproducible)

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
Summary: Breaking quoted line with typed CR loses quote status for end of line → in plain text: breaking quoted line with typed CR loses quote status for end of line because of missing ">" quote sign

can reproduce in

  • TB 115.6.1 @ Win10-64bit
  • TB 128.0a1 (2024-05-27) (64-bit) @ Win10-64bit
Keywords: reproducible

This bug is still reproducible in TB 128.5.2esr.

The analysis by Nelson Bolyard in comment #17 is still accurate and on-point.

Essentially, users should be able to decide what ‘>’-prefixed lines should be quotes or not. Now, a space is silently added before the ‘>’ when it is typed manually or when I copy-paste from a quote. The space should be added non-silently in the composition window as well, but if it is removed, the line should interpreted as being a quote, and colored as such. This allows users to discover this behavior naturally. (They'll think “Why is that space there?” remove it, see the color change, add it back and see the color change again.)

Furthermore, it is essential that only lines with initial ‘>’ (no space in front) are colored, as now it still happens that lines without ‘>’ are colored. Otherwise, the quoting=color logic is broken, which is confusing for users.

I hope this bug will get the attention I feel it deserves again.

N.B.1: In this bug editor I can add a quote myself by just typing a ‘>’ at the line's start:

I am a famous quote

N.B.2: Likely related bugs: Bug 1266173, Bug 1190076

You need to log in before you can comment on or make changes to this bug.