Closed Bug 1356012 Opened 8 years ago Closed 8 years ago

Cannot add quotes manually in plain text compose

Categories

(Thunderbird :: Message Compose Window, defect)

52 Branch
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: programmieren, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 Build ID: 20170330221232 Steps to reproduce: - Choose to send messages as plain text - Write some text, try to add a quote manually by prefixing it with >, e.g. "> quote" Actual results: The actually sent mail contains a space before the >: " > quote" Thus the quote is not recognized. The plain text compose editor does not have any buttons to "format" text as a quote. Expected results: The mails should be sent without the space. This was introduced in Thunderbird 52. Previously it worked by simply prefixing quotes with a >.
Quote processing has changed in TB 52. https://www.mozilla.org/en-US/thunderbird/52.0/releasenotes/ Long lines in plain text replies not properly wrapped I can see that a manually inserted "quote" by inserting a ">" now gets a space prepended. That seems to be an undesired side effect of various other changes we made in bug 387687, bug 1288911, bug 1328093 and bug 1330796. Or maybe this is a side effect of bug 456053. Why don't you use "Paste As Quotation" from the context/right-click menu? Creating manual quotes is not really a valid operation.
The clipboard is not the only source for quotes. There are other sources like letters, books, newspapers …, i.e. text that you type by hand. Other use cases include "quote only one or two words" which might be faster to type instead of select, copy, paste. Independent of the use case there should be a way to format already existing text as a quote without using the "paste as quotation" function. This is not a problem when the rich text editor is used, but the plain text editor does not have any format controls. A (more or less simple) solution might be to add a simplified version of the format toolbar which only contains features that can be applied to plain text, e.g. *…*, /…/, _…_ and >…
I found another use case where this is a problem: Copy text including quotes from a "dumb" mail client that shows only plain text. If you paste this text into Thunderbird, quotes won't be recognized. This might be a rare situation, but nevertheless I would prefer if Thunderbird sends my text like I typed it (that's one of the reasons for using the plain text mode).
Sorry for the noise, I just found another important use case: Write a mail including quotes and then try to re-order sections of the mail via cut & paste. The pasted text lost its quote formatting. "Paste as quotation" does not work in this scenario because the clipboard content does not only include the quote, but also other text (and "paste as quotation" would double the >).
Apparently this only occurs when 'format=flowed' is activated. So try to disable it: <http://kb.mozillazine.org/Mail_content_types#Disabling_paragraph_flow>
Indeed, disabling f=f fixes the problem with quotes, no space is inserted. But that is not a solution because plain text mails without f=f are a pain. (Actually f=f should be enabled by default IMHO.)
(In reply to Sven Greiner from comment #6) > Indeed, disabling f=f fixes the problem with quotes, no space is inserted. > But that is not a solution because plain text mails without f=f are a pain. Inserting a space at f-f is intended. RFC 2646: | 4.4. Space-Stuffing | | In order to allow for unquoted lines which start with ">", and to | [...] | Format=Flowed provides for space-stuffing. | | Space-stuffing adds a single space to the start of any line which | needs protection when the message is generated. [...] So does TB. The '>' char is interpreted as part of the text so a space is added. Therefore, this bug is WONTFIX - IMO This means "Edit"->"Past As Quotation" is the best solution to insert quotes. You may try to select those lines and use "Edit"->"Rewrap". But that scrambles the line breaks - of course.
Thanks for looking into this. I'm not ignoring you, I'm just very busy with other fires right now. I think the discussion so far shows that this is an (undesired) side-effect of fixing bug 456053, where "undesired" may still be according to spec.
@Alfred Peters Yes, that behavior is defined in the RFC and Thunderbird seems to handle it correctly (including the removing of the space during display of a message). Although the behavior is correct I won't call this a WONTFIX. The main issue is that the only way to insert a proper quote is to use "paste as quotation". I showed several examples where this method is not sufficient, e.g. if you "move" text sections via cut & paste. Thunderbird internally uses HTML even for the plain text editor to identify quotes (they are shown as blue text). This format is lost during copy/cut and cannot be set manually. So I see two possible solutions: 1. Recognize > as start of a quote already while writing the mail and apply the format. This might result in undesired quote detection and space-stuffing cannot occur anymore for > (because they are always interpreted as quotes). 2. Add a way to set a paragraph as quote manually, either via a button or the (context) menu. This can be extended by adding a simplified format toolbar as described in comment 2. Additionally the format must be preserved during copy/cut & paste so that text sections including quotes can be moved around. PS: RFC 2646 is superseded by RFC 3676.
(In reply to Jorg K (GMT+2) from comment #8) > Thanks for looking into this. I'm not ignoring you, I'm just very busy with > other fires right now. No hecticness. This is a "not so really urgent" bug ;-) > I think the discussion so far shows that this is an (undesired) side-effect > of fixing bug 456053, where "undesired" may still be according to spec. Thunderbird (51.0a1) - Daily BuildID=20160812164423 Rev: Comm-Central:b2b090d8d57e / Mozilla-Central:b2b090d8d57e (before bug 456053 Comment 77 got landed) - shows the same behavior.
(In reply to Sven Greiner from comment #9) > So I see two possible solutions: > 2. Add a way to set a paragraph as quote manually, either via a button or > the (context) menu. This can be extended by adding a simplified format > toolbar as described in comment 2. Additionally the format must be preserved > during copy/cut & paste so that text sections including quotes can be moved > around. Yes, this would be a good solution. => Bug 460975 > PS: RFC 2646 is superseded by RFC 3676. Yes, but TB has only implemented the first.
(In reply to Alfred Peters from comment #11) > => Bug 460975 No - If I think again, it does not fit. It would add another quote sign, as does "Past As Quotation".
(In reply to Alfred Peters from comment #12) > (In reply to Alfred Peters from comment #11) > > > => Bug 460975 > > No - If I think again, it does not fit. It would add another quote sign, as > does "Past As Quotation". Ok - Finally "Past As Quotation" + "Decrease Quotation Level" will do the trick. O:-)
The current implementation has another bug: - "Paste as quote" something - Remove the leading "> " - Text is still blue (HTML blockquote) Now send the mail. A "> " will be inserted automatically.
(In reply to Sven Greiner from comment #0) > This was introduced in Thunderbird 52. Previously it worked by simply > prefixing quotes with a >. I'm a little frustrated that I fell for this claim. Just confirming in TB 45.8 and TB 38.x: A leading space always got inserted before a > at the beginning of the line. So nothing has changed here in a while. I'm going to close this bug as invalid now (not wontfix). Feel free to open anther enhancement request referencing bug 460975. Please state the use case exactly. There are some suggestions in comment #2 and comment #9. However, I think bug 460975 is already a good fit. If you want to produce > xyz you type xyz and increase the level. Surely "no quote" (level 0) should be promoted to "simple quote" (level 1). Personally, I don't see what wrong with copying the xyz and while it is selected, pasting over it as quotation which replaces the original text.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → INVALID
@Jorg K Nobody blamed you for this. Probably you are right. It is just more visible now because some other bugs regarding plain text and quotes were fixed. I opened another bug report (bug 1357080) and commented on bug 460975.
You need to log in before you can comment on or make changes to this bug.