Open Bug 362194 Opened 18 years ago Updated 2 years ago

Automatic word wrap of quoted long lines inserts extra newlines

Categories

(Thunderbird :: Message Compose Window, defect)

Product:
Thunderbird
Component:
Message Compose Window
Platform:
x86
Windows XP
Type:
defect

Tracking

(Not tracked)

Status:
REOPENED

People

(Reporter: Alexander, Unassigned)

References

Details

(Whiteboard: [steps comment 5])

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; MathPlayer 2.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.1) Build Identifier: Thunderbird 1.5.0.8 (Windows/20061025) Message compose window, plain text mode. Either reply to a received message or paste some paragraphs of text containing long words or long links as quoted (Shift+Strg+V). Then select the automatic re-wrapping option (in German this is "Bearbeiten" -> "Neu umbrechen"). Thunderbird will insert extra lines everytime you repeat the re-wrapping step. Reproducible: Always Steps to Reproduce: 1.Set word wrap to 72 characters. 2. Paste this text as wrapped: 68_chars_01234567890123456789012345678901234567890123456789012345678 69_chars_012345678901234567890123456789012345678901234567890123456789 70_chars_0123456789012345678901234567890123456789012345678901234567890 71_chars_01234567890123456789012345678901234567890123456789012345678901 72_chars_012345678901234567890123456789012345678901234567890123456789012 73_chars_0123456789012345678901234567890123456789012345678901234567890123 3. Select "Edit" -> "re-wrap" (dont't know this option's name in English). 3. Actual Results: After re-wrap #1: > 68_chars_01234567890123456789012345678901234567890123456789012345678 > 69_chars_012345678901234567890123456789012345678901234567890123456789 > > 70_chars_0123456789012345678901234567890123456789012345678901234567890 > > 71_chars_01234567890123456789012345678901234567890123456789012345678901 > > 72_chars_012345678901234567890123456789012345678901234567890123456789012 > > 73_chars_0123456789012345678901234567890123456789012345678901234567890123 After re-wrap #2: > 68_chars_01234567890123456789012345678901234567890123456789012345678 > > 69_chars_012345678901234567890123456789012345678901234567890123456789 > > > 70_chars_0123456789012345678901234567890123456789012345678901234567890 > > > 71_chars_01234567890123456789012345678901234567890123456789012345678901 > > > 72_chars_012345678901234567890123456789012345678901234567890123456789012 > > > 73_chars_0123456789012345678901234567890123456789012345678901234567890123 After re-wrap #3: > 68_chars_01234567890123456789012345678901234567890123456789012345678 > > 69_chars_012345678901234567890123456789012345678901234567890123456789 > > > > 70_chars_0123456789012345678901234567890123456789012345678901234567890 > > > > 71_chars_01234567890123456789012345678901234567890123456789012345678901 > > > > 72_chars_012345678901234567890123456789012345678901234567890123456789012 > > > > 73_chars_0123456789012345678901234567890123456789012345678901234567890123 And so forth. Expected Results: > 68_chars_01234567890123456789012345678901234567890123456789012345678 > 69_chars_012345678901234567890123456789012345678901234567890123456789 > 70_chars_0123456789012345678901234567890123456789012345678901234567890 > 71_chars_01234567890123456789012345678901234567890123456789012345678901 > 72_chars_012345678901234567890123456789012345678901234567890123456789012 > 73_chars_0123456789012345678901234567890123456789012345678901234567890123
Please don't submit the same bug twice, if you have additional information to add, you can leave a comment on your original bug report. Thanks. *** This bug has been marked as a duplicate of 362192 ***
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
Please read my two bug descriptions more carefully. I put quite some effort in filing two reports for similar, but nevertheless non-identical issues. Thanks.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Assignee: mscott → nobody
Reporter, does the issue still occur in the latest supported 2.0.0.x / Shredder trunk nightlies? (1.5.0.x is now end-of-life and the latest supported 2.0.0.x is 2.0.0.17)
Whiteboard: closeme 2008-10-23
Is this the way bugs are handled here? Wait for two years, do nothing and then ask if the bug is still there? Very strange indeed. Yes, the bug still occurs in 2.0.0.17, exactly as before.
Whiteboard: closeme 2008-10-23
Confirming for current TB12 and Trunk. STR 1 Compose, Options > Format > Plaintext only (with default setting for mailnews.wraplength = 72) 2 Copy and *Paste as quotation* the following text: 68_chars_01234567890123456789012345678901234567890123456789012345678 69_chars_012345678901234567890123456789012345678901234567890123456789 70_chars_0123456789012345678901234567890123456789012345678901234567890 71_chars_01234567890123456789012345678901234567890123456789012345678901 72_chars_012345678901234567890123456789012345678901234567890123456789012 73_chars_0123456789012345678901234567890123456789012345678901234567890123 3 Press Ctrl+R to rewrap msg 4 Repeat Step 3 several times Actual Result After Step 2: pasted text is inserted nicely as formatted quote with vertical border line on the left as in HTML format (I wonder if that formatting is correct as we are in plain-text mode?) After Step 3: (see copy of result text below) quote is converted to plaintext (using > as quote indicator) and wrapping is messed up in unexpected ways (e.g. line with 70 characters is wrapped and loses the quote indicator (compare black and blue font color), while line with 73 character is *not* wrapped. After repeating Step 3 another 3 times: quote continues to grow, extra newlines are inserted each time Ctrl+R is pressed: Rewrap 2: +3 empty newlines introduced by > Rewrap 3: +1 empty newlines with > between lines with original 70 and 71 characters Rewrap 4: +1 empty newlines with > between lines with original 70 and 71 characters (each new repwrap adds another newline there) Expected Result: - check if output after step 2 does the right thing for plaintext - less messy output after Steps 3 and 4: - don't add extra newlines when re-wrapping (especially when text has just been rewrapped!) - ensure all quoted lines remain quoted with > ************************************************************ Actual Result After Step 3: > 68_chars_01234567890123456789012345678901234567890123456789012345678 > 69_chars_012345678901234567890123456789012345678901234567890123456789 > > 70_chars_0123456789012345678901234567890123456789012345678901234567890 > 71_chars_01234567890123456789012345678901234567890123456789012345678901 > > 72_chars_012345678901234567890123456789012345678901234567890123456789012 > 73_chars_0123456789012345678901234567890123456789012345678901234567890123 Actual Result After step repeating Step 3 another 3 times: > 68_chars_01234567890123456789012345678901234567890123456789012345678 > > 69_chars_012345678901234567890123456789012345678901234567890123456789 > > 70_chars_0123456789012345678901234567890123456789012345678901234567890 > > > > 71_chars_01234567890123456789012345678901234567890123456789012345678901 > > 72_chars_012345678901234567890123456789012345678901234567890123456789012 > 73_chars_0123456789012345678901234567890123456789012345678901234567890123
Status: UNCONFIRMED → NEW
Ever confirmed: true
I've closed Bug 487954 which thomasd pointed out is similar to this. Using current daily build I can't reproduce using steps of comment 5.
Status: NEW → RESOLVED
Closed: 18 years ago → 10 years ago
Resolution: --- → WORKSFORME
What the heck? You let this bug rot for 8 (in words: eight!) years and then just close it? I just retried in TB 24.6 and it is still perfectly reproduceable. This has been bugging me every single day since I first used Thunderbird long ago and it was never fixed. Wrapping/reformatting quoted text is just broken, period. Please re-test and fix. Thanks.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
You seem to miss the point that I did test it, and stated so. And, I understand you are frustrated but I personally didn't let it rot. Please note, the bugzilla status field is intended to reflect what anyone can reproduce in the most current development version (33) of code. You can get and test from daily builds at https://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-central/ Does problem reproduce for you with the daily build?
Flags: needinfo?(bugzilla2007)
Flags: needinfo?(Alexander)
I have not missed anything, dear Wayne. I just think you missed my description how to test. I wrote "paste (...) *as wrapped*", i.e. as quotation (Shift-Ctrl-O). Have you done that? I have and can easily reproduce the problem with current release *and* with current daily 33.0a1 (2014-06-13). Please re-test.
Flags: needinfo?(Alexander)
Thanks for pointing out the error. Thomas fixed step 2 in comment 5. 2. Paste this text as Quotation:
Flags: needinfo?(bugzilla2007)
Whiteboard: [steps comment 5]
See Also: → 1433942
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.