It seems thunderbird renders a super strange quotation effect when finding this text in a message line: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> For an example, subscribe to nntp://news.gmane.org/gmane.comp.gnome.mono.bugs and open the message called "[Bug 419989] Mono crashes in x86_64 SLES10 SP2 (OES2 SP1) virtualized environment - XEN" on date 09-Sep-2008.

duplicate

Bug 191881 is about the Rewrap command. Where is there any mention of that here?

Reason for resolution?

(In reply to Andrés G. Aragoneses from comment #3) > Reason for resolution? Incomplete - as stated when I resolved it. It's incomplete because it doesn't meet the requirements of a proper bug report, as laid out in the Bug Writing Guidelines (1) or Starter kit's "How to write a proper bug" (2). More specifically: - poor summary: what is "super strange quotation effect", where does it happen and how to get there? - no steps to reproduce (lacking necessary detail - e.g. is this message reader or composition? composition also renders quotations when replying...) - no testcase, no screenshots... (don't expect others to go through the hassle of subscribing to a newsgroup just to reproduce your little problem when a simple testcase msg added as an attachment to this bug would suffice) The net result of such an incomplete report is that it nobody will understand it, hence it is not actionable. That's why there has been basically no activity on this bug since 2008. Fwiw, with some guesswork and goodwill, I was able to reproduce the bug and admittedly "super strange quotation effect" is pretty good description of that beautiful piece of "line art" (in its most literal sense) seen when message reader renders the sequence of closing angle brackets presented in comment 0: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in a msg of this type: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit (1) https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines?redirectlocale=en-US&redirectslug=Bug_writing_guidelines#Writing_precise_steps_to_reproduce (2) https://quality.mozilla.org/docs/bugzilla/starter-kit/how-to-write-a-proper-bug/

We also need to explain why this is a bug, for which you need to add "Actual result" and "Expected result". As a preliminary note, I agree that this is a bug because when composing in rich text mode (HTML), TB should render > as a normal character as there is no reason to assume plain-text quotations. So we're violating UX-wysiwyg, and I suspect this is an unintended side-effect of Options > Format > Auto-Detect, similar to those violations of UX-wysiwyg seen in Bug 414299 (Format > Auto-Detect dumps HTML formatting of <pre> and <tt> tags) and Bug 414299 Comment 108 (Format > Auto-Detect dumps HTML formatting via css style attributes).

Further observations: There are two problems here, A and B. A) Format > Auto-Detect causes dataloss of formatting and content A1) Starting out from HTML composition having: <pre>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;</pre> Important: <pre> seems necessary to reproduce. Since we're in rich text (HTML) composition, TB has no reason to assume that these characters indicate quotes (which only applies for plaintext), if only to respect UX-wysiwyg. A2) Format > Auto-Detect first wrongly removes the </pre> (as reported in bug 414299) and down-converts the msg to plaintext format=flowed. That's dataloss because <pre> tags and the corresponding formatting are lost. A3) Conversion by Auto-Detect then fails to consider the angle brackets as actual characters for the purposes of composition/sending. Even for the wrongly chosen plaintext/format=flowed, the angle brackets from the rich composition of A1 would need to be preserved by adding a space character in front of that row (space-stuffing, see http://tools.ietf.org/html/rfc3676#section-4.4). Instead it wrongly considers them as quote characters. That's dataloss, because the sender's actual content is distorted. B) TB message reader exposes graphical rendering problems with vertical quote lines when they overlap from left and right B1) In general, TB renders message of type plaintext/format=flowed having a non-space-stuffed line of >>>> characters correctly: each > is considered a quote character, and nested quotes are then rendered as "nested" vertical lines becoming smaller from outside (left/right) to inside. B2) However, if horizontal viewing space available for msg reader widget is too little so that vertical lines coming from left and right partially overlap ("super strange quotation effect"), the overlap looks distorted (although I'm not sure how it /should/ look if there was any text in between, it would be a mess anyway). While I find problem A) disturbing because of its dataloss nature, problem B) might be negligible.

(In reply to Thomas D. from comment #6) > A) Format > Auto-Detect causes dataloss of formatting and content > Important: <pre> seems necessary to reproduce. Might also happen for all such tags that overzealous algorithm of Format > Auto-Detect dumps when down-converting to plaintext because of wrongly considering them "inconsequential formatting".

This is the draft msg having plain >>> characters. We're in HTML composition, so this isn't about nested quotes in any way, as correctly seen in composition window and HTML source code having <pre>&gt;&gt;&gt;</pre> Scenarios: using >>> for decoration, emphasis, tearline - whatever: TB must not judge about users intentions and contents, we're just the messenger

Screenshot of Composition / Saved Draft of Testcase 1a, correctly showing >>> as characters - as expected and explained above, before sending.

These are the remains of testcase 1a after sending. Upon sending, Format > Auto-Detect downconverts the msg to text/plain; format=flowed because <pre> is wrongly considered inconsequential formatting: Bug 414299 - Format > Auto-Detect dumps HTML formatting of <pre> and <tt> tags Fixing bug 414299 (by preserving <pre> tags) will fix this bug; however, this is a separate bug because even if Auto-Detect insists on dumping tags deemed inconsequential, it needs to ensure that text contents are preserved according the conventions of rfc3676#section-4.4. In this case: > Even for the > wrongly chosen plaintext/format=flowed, the angle brackets from the rich > composition of A1 would need to be preserved by adding a space character in > front of that row (space-stuffing, see > http://tools.ietf.org/html/rfc3676#section-4.4). _>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (where _ indicates the space required to preserve the text content) Because Auto-Detect fails to do space-stuffing to preserve the text content, it sends out a plain row of >>> characters instead which according to rfc3676 must be rendered as nested quotes. That's violating ux-wysiwyg and dataloss, because the sender's actual HTML text content is distorted between composition and sending, which necessarily leads to wrong rendering for recipients whose clients correctly parse format=flowed per rfc3676.

This is screenshot of attachment 732719 [details], as described in previous comment 10: Sent msg after unwarranted and technically wrong downconverting to text-plain;format=flowed by Format > Auto-Detect, in violation of rfc367 (http://tools.ietf.org/html/rfc3676#section-4.4). (In reply to Thomas D. from comment #10) > Testcase 1b: Sent.eml (downconverted to text-plain;f-f by Format > > Auto-Detect) > > These are the remains of testcase 1a after sending. > Upon sending, Format > Auto-Detect downconverts the msg to text/plain; > format=flowed > [...]

(In reply to Thomas D. from comment #6) > B) TB message reader exposes graphical rendering problems with vertical > quote lines when they overlap from left and right Screenshot 1b of attachment 732721 [details] also exposes that little graphical distortion when TB's vertical quote lines start to overlap from left & right: a) quote lines coming from right side are discontinued half-way (perhaps "folded" to run back to the right) b) quote lines left/right overlap section has graphical distortions (showing "triple" instead of "dual" lines; perhaps related to or same as a)). If at all, I'd prefer have that treated that in a separate bug, because that's trivial and pretty inconsequential.

STR: 1) HTML composition using TB's current default settings: - Format > Auto-Detect - Recipient's HTML preference in AB: unknown - [x] Compose messages in HTML format set in Account Settings > Composition & Adressing 2) Open Testcase 1a of attachment 732709 [details], which is HTML composition essentially having this markup in HTML source: <pre>&gt;&gt;&gt;</pre> ...correctly seen in composition as in Screenshot 1b of attachment 732710 [details]: >>> (without the leading space) (Alternatively, type >>>, select and apply "Preformat" from formatting toolbar) 3) Send later (Ctrl+Shift+Enter) with default settings of 1) 4) View sent message from Outbox (as it will be sent to recipient): 4a) msg content (visually) 4b) msg source (Ctrl+U) Actual result 4a) sent msg content (visually): see Screenshot 1b of attachment 732721 [details] "Super strange quotation effect" of multiple nested quotations (vertical lines in TB) with partial overlap and minor graphical distortions: (In reply to Thomas D. from comment #12) > a) quote lines coming from right side are discontinued half-way (perhaps > "folded" to run back to the right) > b) quote lines left/right overlap section has graphical distortions (showing > "triple" instead of "dual" lines; perhaps related to or same as a)). More importantly: - violates ux-wysiwyg beetween what is composed and what is sent out: TB cannot assume user intention of sending nested quotes, because this isn't a plaintext composition - dataloss, see 4b below 4b) sent msg source (Ctrl+U) Format > Auto-Detect downconverted msg from HTML to text-plain;format=flowed Relevant source code is now: >>> (without the leading space) Format=flowed forces rendering of >>> (without leading space) as nested quotations on any rfc3676 compliant mail client, which is dataloss because original text / logical text quality of >>> characters is "lost" when correctly rendered by rfc3676 compliant mail client. Expected result: 4a)b) honor ux-wysiwyg and content integrity between composition and sending: - don't remove <pre> tags (Bug 414299) (imo best and most simple way to fix this) - or, as a minmal fix, at least apply space-stuffing per rfc3676 (1) to preserve logical text quality of >>> characters when downconverting to text/plain;format=flowed (1) http://tools.ietf.org/html/rfc3676#section-4.4

(In reply to Thomas D. from comment #13) > Actual result > 4b) sent msg source (Ctrl+U) ...as found in testcase 1b draft.eml of attachment 732719 [details]

@Andrés (reporter): q.e.d. :) Thanks for filing!

(In reply to Thomas D. from comment #15) > @Andrés (reporter): q.e.d. :) > > Thanks for filing! Thanks for completing.