187997 - Rewrap doesn't work with selected text

Status: RESOLVED FIXED

(MailNews Core :: Composition, defect)

Description

[Max Waterman]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3b) Gecko/20030102
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3b) Gecko/20030102

I just had an email with one long line and some formatted text separated by a
blank line.

When I viewed the message, the long line was wrapped, as expected.

When I replied to the message, the long line was quoted unwrapped, and the
formatted text was quoted, as expected.

If I then rewrapped the whole message, the long line is rewrapped correctly, but
the formatted text was also rewrapped so that it was no longer formatted. To get
around this, I selected just the long line and tried to rewrap that, but,
unfortunately, it did not correctly maintain the quoting of that line.

As an example, this is the long line I received :

<quote>
Attached is an image I made by putting all of the windows onto one pipe.  There
is a black mat (rendered once into the stencil planes) that shows what each
panel of the dome looks like.  Perfly's output should look something like ours,
minus these black mats.  If this output is needed without the black mats, let me
know and I will send it out. 

The view frustum for each channel is listed below.

pipe 0 
        hpr       118.16  15.22   8.13;
        frust   -36.55  36.55   -32.23  37.93;
</quote>

Replying to this produces a compose window with this in it :

<quote>
> All,
> 
> Attached is an image I made by putting all of the windows onto one pipe. 
There is a black mat (rendered once into the stencil planes) that shows what
each panel of the dome looks like.  Perfly's output should look something like
ours, minus these black mats.  If this output is needed without the black mats,
let me know and I will send it out.  
> 
> The view frustum for each channel is listed below.
> 
> pipe 0 
>         hpr       118.16  15.22   8.13;
>         frust   -36.55  36.55   -32.23  37.93;
</quote>

If I now select 'Edit/Rewrap', it produces :

<quote>
> All,
> 
> Attached is an image I made by putting all of the windows onto one
> pipe.  There is a black mat (rendered once into the stencil planes)
> that shows what each panel of the dome looks like.  Perfly's output
> should look something like ours, minus these black mats.  If this
> output is needed without the black mats, let me know and I will send
> it out.
> 
> The view frustum for each channel is listed below.
> 
> pipe 0 hpr       118.16  15.22   8.13; frust   -36.55  36.55   -32.23
> 37.93; pipe 1 hpr       61.84   -15.22  -27.87; frust   -36.55  36.55
</quote>

See that the long line is correctly rewrapped, but the last lines are not as
desired. So selecting just the long line and then rewrapping should be the thing
to do, but it produces :

<quote>
> 
> Attached is an image I made by putting all of the windows onto one
pipe. There is a black mat (rendered once into the stencil planes) that
shows what each panel of the dome looks like. Perfly's output should
look something like ours, minus these black mats. If this output is
needed without the black mats, let me know and I will send it out.
> 
> The view frustum for each channel is listed below.
> 
> pipe 0 
>         hpr       118.16  15.22   8.13;
>         frust   -36.55  36.55   -32.23  37.93
</quote>

I hope that makes this clear.

Reproducible: Always

Steps to Reproduce:
1.reply to an email with long line
2.rewrap entire message results in correctly quoted 
3.selecting just the long line and rewrap results in wrongly quoted text

Actual Results:  
incorrect wrapping

Expected Results:  
correct wrapping

Comment 1

[Boris 'pi' Piwinger]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030117

I see it. Assigning to Akkana.

pi

Comment 2

[Akkana Peck]

I just tried it : I didn't have a message with a long line handy, so I replied
to a message, typed some stuff on one of the quoted lines to make a long quoted
line, then I selected only that line (including the > characters at the
beginning of the line) and did Rewrap.  I got four wrapped lines at the same
level of quoting (in this case, ">> ") as the original long line, exactly what I
expected.

Can someone clarify: exactly what are you selecting, and what happens when you
do a rewrap with that selection?  Does my having edited the quote somehow throw
things off so that the bug doesn't happen?  (It shouldn't make any difference,
AFAIK.)

Are you perhaps selecting without the quote characters?  The rewrap code has no
way of knowing the quote level if it's rewrapping text that has no quote
characters in it.

Comment 3

[Max Waterman]

Attachment: Before rewrap

This is before doing the 'rewrap'.

Notice the text that I have selected in blue.
Notice the long lines - they go off the side of the window as shown by the
scroll bar.

Comment 4

[Max Waterman]

Attachment: After rewrap

This is after the rewrap. Notice the bad quoting, even though it is the
simplest case.

Comment 5

[Max Waterman]

Attachment: before delete

This is showing errant cursor control. The screen grab doesn't show the cursor,
but it is positioned before the 'a' in 'and' shown by the red arrow.

Comment 6

[Max Waterman]

Attachment: after delete

This images is what happens if you press delete in an attempt to delete the CR
and move the 'and' up to the previous line - it does move the line up, but you
lose the 'a' from 'and'.

Comment 7

[Max Waterman]

Attachment: before insert

This shows the cursor position before I attempt to re-insert the 'a' before the
'nd' to recreate the word 'and'.

Comment 8

[Max Waterman]

Attachment: after inserting 'a'

Here is what it looks like after I press 'a'. It inserts 'a' fine, but moves
down the entire line as if it were a single word. I could understand it moving
down the word at the end of the line, but not the whole line.

Comment 9

[Max Waterman]

I am highly suspicious of some strange interaction between the rewrap
functionality and the autowrap functionality....let me look at what settings I
have - ah, 'Wrap plain text messages at <72> characters'.

Do you have this set to anything?

Max.

Comment 10

[Boris 'pi' Piwinger]

Attachment: Mail from original report.

Akkana, you asked for an example mail.

pi

Comment 11

[Akkana Peck]

Aha!  I had a spurious wrap_to_window_width setting in my prefs.  When I remove
that and try wrapping the long line in Boris' attachment, I see a quote level
problem: the first wrapped line is quoted, and the rest of the old line is left
unquoted, like so (same problem that Max described at the end of his original
report):

> here is the first part of the selected long line
and here is the continuation of that same long line
and some more continuation
> here is the first line that wasn't in the selection

Any idea if this is a recent regression, or if it's been doing this for a long
time?  This is pretty bad, and I thought this worked. :-(

Comment 12

[Max Waterman]

I time I filed this bug is pretty much the first time I noticed the 'rewrap'
function, and so I don't know how much older this bug is than this report.

Max.

Comment 13

[Mike Cowperthwaite]

I have attempted to reproduce this bug using the reporter's original text.  I 
sent myself a mail containing that text, with the longer paragraph merged into a 
single line.  I sent the text f=f, but f=f text is wrapped automatically on 
quote (but not necessarily to the correct width, see bug 173918).  (Non-f=f text 
composed in Mozilla will have line breaks in it, and so be quoted as multiple 
lines as well.)

Therefore, I took two paths in testing this.  First, I created a 'quoted reply' 
using Paste As Quote; and second, I merged the email attached to this bug into a 
mail folder for quoting.  The behavior between the two differs a bit.  Results 
are from
  Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031003

PASTE AS QUOTE (four tests)
I copied the text from the original message and put it into the compose window 
with Paste As Quote. The text was inserted with the caret (|) positioned as 
shown, at the very start of the window:
|>
 > The view frustum for each channel is listed below.

After the paste, the text looked like:
 > Attached is an image I made by putting all of the windows [...]

|>
 > The view frustum for each channel is listed below.

Note the blank line between the pasted text and the first, empty quote line.  
Typing on the blank line shows as blue, so it is still part of the quoted-text 
span.  The line is blank if the end-of-line from the original text is not 
included in the copy buffer; if the end-of-line *is* included, the blank line 
appears as another empty quote line.  The rewrap behavior does not change, 
either way.

I then selected the line and rewrapped; the wrapped lines were mis-quoted as 
described in the bug.  After the rewrap, the caret appears on the blank line; 
typing behaves as you might expect.

I repeated this series of steps, but typed backspace to delete the blank line 
before selecting Rewrap; in this case, the resultant text was:
> Attached is an image I made by putting all of the windows onto one
> [... etc ...]
> output is needed without the black mats, let me know and I will send
> it out.> 
> The view frustum for each channel is listed below.

Note that the empty quote line was glommed into the rewrapped text, altho it was 
not part of the selection.  The caret was positioned at the end of the first 
line of the rewrapped text (after "one"); but attempting to type at this point, 
the caret jumps to the end of the rewrapped section between "out." and ">", and 
the typed characters are inserted there.

Once again, I used Paste As Quote to set up the text.  This time, I selected 
both the long line and the empty line that was pasted below it; in this case, 
selecting Rewrap performed the quoting correctly, but left the blank line 
underneath.  The caret was placed at the beginning of the blank line; attempting 
to type at this point caused the caret to jump to the beginning of the empty 
quote on the next line -- that is, jumped to immediately *before* the '>'.

Finally, I again used Paste As Quote followed by backspace; then I selected the 
long line plus the empty quote line that had been there previously.  Selecting 
Rewrap generated the desired results.  The caret was on the empty quote line; on 
attempting to type, it jumped to the beginning of the of the quote on the next 
line -- again, before the '>'.

In each case where the caret would jump on typing, backspacing over the typed 
characters put the caret back where it started.  Typing again, the caret jumps 
again.  However, as soon as an arrow key is used to cursor the caret, all 
behaves as expected.

REPLY TO MESSAGE (two tests)

Replying to the message, the quote appears with the long line unbroken, as 
described.  I tried rewrapping with just the one line selected, and also with 
the one line plus the following empty quote line selected.  In each case, the 
wrapping was as described; the caret was placed immediately prior to the '>' on 
the first unselected line; and typing behaved normally.

I realize the whole Paste As Quote thing is kind of orthogonal to this bug, but 
given the various similarities and differences, I thought the results could shed 
some light on the problem here.

The jumping caret is probably its own bug; I would say the blank line being 
inserted after Paste As Quote is a bug too.

Comment 14

[Max Waterman]

FWI I've been using thunderbird for a while now, and I see this same problem in
version 0.6 (20040502).

Anyone looking at fixing this?

Comment 15

[Simon Billingsley]

*** Bug 216744 has been marked as a duplicate of this bug. ***

Comment 16

[Todd]

Attachment: Example of rewrap selection not working right

This shows what happens sometimes when rewrapping a block that's caret-quoted,
and barely longer than the desired line length.  I'm using the Thunderbird 0.7
release, build 20040616.  Oddly enough, if I correct its quoting/blankline
errors (but not the wrapping) and try again, it rewraps correctly just about
every time.  See example.

Comment 17

[Todd]

I forgot to mention that my example is what happens when I select just part of a
message and choose rewrap, rather than with all or none of it selected; that
works fine.

Comment 18

[Mike Cowperthwaite]

*** Bug 278258 has been marked as a duplicate of this bug. ***

Comment 19

[Mike Cowperthwaite]

*** Bug 325172 has been marked as a duplicate of this bug. ***

Comment 20

[troy]

(Linux, 1.5.0.4)

This is how I see it:  Rewraps on *selections* only work well if the selection contains at least one line that does NOT start with ">".  

> blah
>
> this is a extra super idiotic and foolish long line long extra long .....
> here comes the second unbroken line like stupid mailers do send .....
>
> blah

If you select only the middle two lines, it behaves poorly.
Even if you select all 6 lines (being careful not to get the 
7th as well), it behaves poorly.
 
If your selection includes any line that doesn't start with ">", 
it works well.  People who can't reproduce this may be selecting
past the 6th line (getting the 6th CR).

The rewrap feature has behaved this way for a long time.

A work-around is inserting empty lines and including them in your
rewrap selection.

Comment 21

[Paolo Bonzini]

Based on comment #20, I think this bug is now fixed, everything that's left is a dup of either bug 121898 or bug 191881.

Comment 22

[reid]

Paolo,

I disagree - I looked at the two bugs you reference, and I don't see how they apply. Here's my experience:

== Steps to reproduce ==

1. Find an e-mail with a very long line.
2. Reply to it. In the quoted text, the long line should extend off the right side of the screen.
3. Triple-click on the long line to select it.
4. Choose Edit->Rewrap.

== Expected behavior ==

Line is wrapped into multiple lines, each prefixed with ">", e.g.:

> Line 1
> Line 2
> Line 3

== Actual behavior ==

Only the first line is prefixed with ">", and it's broken into a long part and a very short part. Subsequent lines are wrapped but do not have the prefix. E.g.:

> Most of line 1
> Part of line 1
Line 2
Line 3

== Additional comments ==

This happens in a newly-installed Thunderbird 3.1 on Mac OS X.

IMO this is a significant usability bug, and frankly it's embarrassing that it has persisted so long. The suggested workaround (add extra blank lines) is extremely obscure and definitely not expected behavior.

It's clear that Thunderbird knows how to wrap the paragraph correctly (given that the workaround exists). This code should simply be enabled when a selection contains only quoted lines.

Comment 23

[Paolo Bonzini]

The text of comment #20 probably was not long enough so I could not reproduce it.  Can you please find one such email and attach it here as a .eml file so that we have a standard test case?  Thanks!

Comment 24

[Nelson Bolyard (seldom reads bugmail)]

Reidster,
I completely confirm what you see.  I see it every day.  
Whenever I compose email in TBird, I spend as much time working around 
TBird's problems as I do just entering the text I want it to have. 

Get an email, bonk reply, spend 10 minutes cleaning up the terrible mess 
before you can enter your own text.  

After 7 years, I've learned it's pointless to report mail TB composer bugs. 
You have to get into the Zen of Thunderbird.  It is what it is.

Next time you're frustrated with it, try consuming mind altering substances
and then repeatedly chant Thunderbird's Mantra ("GLOda, GLOda, GLOda") until they take effect.

Comment 25

[reid]

Attachment: New example, per request

Paolo,

Sure! Here is a test e-mail. Just open it as a saved message and reply to it, and in the you can demonstrate the behavior in the reply's composition window.

Comment 26

[troy]

FWIW, using the attachment from comment 25 and TRIPLE CLICK as suggested in comment 22, here's what I see on TB 3.1 on OS X:

The first long line (which is followed by a line consisting of "> ") rewraps correctly.  The other long lines, followed by either more quoted text or nothing, don't wrap correctly.

Also, if I select the last line manually by clicking and sweeping down into open space, that selection will rewrap correctly.  I assume the difference between that and the triple click selection is the inclusion of the CR and/or LF.

Clearly the rewrap code is sensitive to the last characters in the selection and/or those immediately after the selection.

Comment 27

[Tom Honermann]

The issue described in comment 22 and comment 26 are still present in ThunderBird 12.0.1 (Windows).  I would love to see this corrected!

Comment 28

[Nicolas Dietrich [:nidi]]

The issue still exist in Thunderbird 15.0.1 (Linux) and is pretty annoying, as it makes the manual rewrap feature rather useless.

Comment 29

[Glenn Knickerbocker]

Still there in Thunderbird 17.0 . . .

Comment 30

[Glenn Knickerbocker]

Seems OK now in TB24.

Comment 31

[Glenn Knickerbocker]

Spoke too soon.  It worked OK on lines that were already within the length limit, but reformatting a very long quoted line still causes it to wrap without quote characters.

Comment 32

[David E. Ross]

Windows 7 (x64)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1

I have seen this problem through many past versions of Thunderbird.  I see two forms of this problem.  

1.  I select a block of quoted lines (with the > quote indicator) in a plain-text message within a larger block of lines.  I then select Rewrap, and the wrapping occurs okay.  However, only the first line of the result has the > quote indicator in the left margin.  

2.  I place two blank lines before and two blank lines after the block I want to rewrap.  Each blank line consists solely of a CR.  I insert a > quote indicator in the left margin in the line immediately before the block and in the line immediately after the block.  I select the quoted block including the two blank lines with the > quote indicators immediately adjacent to the target block.  I then select Rewrap.  Not only does the wrapping occur okay, but also all lines in the block now have the > quote indicator.  However, the blank line with the > quote indicator immediately before the block now has a space between the > and the CR; and it is now separated from the block by a new blank line consisting solely of a CR.

Comment 33

[David E. Ross]

Attachment: before rewrap

This is a contrived example.  However, I contrive this every time I want to rewrap quoted text in a plain-text message.

Comment 34

[David E. Ross]

Attachment: selected block

This shows how I select the block to be rewrapped.

Comment 35

[David E. Ross]

Attachment: after rewrap

This show the result of wrapping.  Notice the new blank line, the 4th line.  If I move my cursor over the 3rd line but to the right, it demonstrates a blank character has been added.

Comment 36

[David E. Ross]

Re comment #32:

Case #2 only works if any quoted blank lines within the block to be rewrapped have no blank spaces between the quote indicator (>) and its CR.

Comment 37

[Pierre Ossman]

It's been a couple of years since the last update to this bug, but the issue remains in TB 45. Comment 20 still seems to work as a workaround.

Comment 38

[Wayne Mery (:wsmwk)]

Bug 234029 a duplicate?

Comment 39

[Max Emig [:maxe]]

Attachment: Bug 187997 - Maintain quoting when rewrapping a selection inside a mail quote. r=edgar

Comment 41

[Francesco]

Please note bug 2048095 comment 25:

The result depends on what exactly is selected. If only the quote is selected, the rewrap fails. If the linebreak after the quote is also selected, the rewrap works.

Hopefully the patch will take care of this.

Comment 42

[Max Emig [:maxe]]

Hopefully the patch will take care of this.

Yes, it does.

The only point mentioned in this bug it does not take care of is that > (zero trailing white spaces) and > (two or more trailing white spaces) currently both become > (one trailing white space) when rewrapped, because it is asserted in a pre-existing test and handled in a totally different place and I feel might not even be undesired in the broader sense.

Comment 43

[Francesco]

I'm taking the liberty to change the status to ASSIGNED, since you presented a patch. Please revert, if that's incorrect.

Comment 44

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/dafe3b93bdaf
https://hg.mozilla.org/integration/autoland/rev/5499394d0047
Maintain quoting when rewrapping a selection inside a mail quote. r=edgar

Comment 45

[Max Emig [:maxe]]

Please verify this with tomorrows Daily.

Keep in mind, if you do not include the initial > with your selection for rewrap, it correctly does not generate any new >.

Comment 46

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/5499394d0047

Comment 47

[Francesco]

Daily today it broken. I'll check it when I can.

Comment 48

[Francesco]

So this is about various selections in the sample mail in attachment 9598222 [details], basically:

> Lorem Ipsum is simply dummy text ... including versions of Lorem Ipsum.

In the following, [] denotes the selection.

This case always worked and continues to work:

[> Lorem Ipsum is simply dummy text ... including versions of Lorem Ipsum.]

This case didn't work before the patch, but works now. It has the line break at the end selected as well:

[> Lorem Ipsum is simply dummy text ... including versions of Lorem Ipsum.
]

However, when selecting part of the quote and including a space at the end of the selection

[> Lorem Ipsum is simply dummy text ... including versions ]of Lorem Ipsum.

this space is removed in the result, which isn't correct:

> Lorem Ipsum is simply dummy text ... 
> ... including versionsof Lorem Ipsum.

So in summary, this has improved, but there is further room for improvement. Maybe you can handle the "selection with trailing space" better.

Comment 49

[Francesco]

There are obviously more test case with partial selection of the quote, like mid-to-end, mid-to-mid, with various space inclusions/exclusions. Maybe it would be easier to always consider the quote fully selected.

Comment 50

[Max Emig [:maxe]]

this space is removed in the result, which isn't correct:

Are there any other users preferring keeping the space instead of the status quo of removing it?

In general, the current rewrap can only see the context that was selected, not before and not after. For example, if the > isn't included in the initial selection, none of the new lines emitted by the rewrap will carry the > with them.

Comment 51

[Francesco]

No users present here. If you want user feedback, ask on these newsgroups:
alt.comp.software.thunderbird - de.comm.software.mozilla.mailnews

Why would any user prefer the incorrect action of deleting a space and gluing two words together?

Comment 52

[Max Emig [:maxe]]

Why would any user prefer the incorrect action of deleting a space and gluing two words together?

Because for fully selected lines this cleans up a formatting mess.

Comment 53

[Francesco]

I don't understand, the result needs further manual intervention before being useful.

Comment 54

[Max Emig [:maxe]]

(In reply to Francesco from comment #53)

I don't understand, the result needs further manual intervention before being useful.

IMO, more users will have complete lines selected and be happy about the polished result of that than the niche usecase of rewrapping a partially selected line.

I had even considered enforcing rewrapping to always do full lines.

Needs more feedback, feel free to point me to user opinions on other platforms/communication channels.

Comment 55

[Francesco]

Looks like this bug is done then. I'll file a follow-up.