Open Bug 187997 Opened 19 years ago Updated 3 years ago

Rewrap doesn't work with selected text

Categories

(MailNews Core :: Composition, defect)

defect
Not set
normal

Tracking

(Not tracked)

People

(Reporter: davidmaxwaterman, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(12 files)

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
Blocks: rewrap
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030117

I see it. Assigning to Akkana.

pi
Assignee: ducarroz → akkana
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: MacOS X → All
Hardware: Macintosh → All
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.
Attached image 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.
Attached image After rewrap
This is after the rewrap. Notice the bad quoting, even though it is the
simplest case.
Attached image 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.
Attached image 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'.
Attached image before insert
This shows the cursor position before I attempt to re-insert the 'a' before the
'nd' to recreate the word 'and'.
Attached image 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.
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.
Akkana, you asked for an example mail.

pi
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. :-(
Status: NEW → ASSIGNED
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.
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.
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?
*** Bug 216744 has been marked as a duplicate of this bug. ***
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.
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.
Product: MailNews → Core
*** Bug 278258 has been marked as a duplicate of this bug. ***
*** Bug 325172 has been marked as a duplicate of this bug. ***
(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.
Assignee: akkzilla → nobody
Status: ASSIGNED → NEW
QA Contact: esther → composition
Product: Core → MailNews Core
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.
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.
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!
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.
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.
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.
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!
The issue still exist in Thunderbird 15.0.1 (Linux) and is pretty annoying, as it makes the manual rewrap feature rather useless.
Still there in Thunderbird 17.0 . . .
Seems OK now in TB24.
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.
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.
Attached image before rewrap
This is a contrived example.  However, I contrive this every time I want to rewrap quoted text in a plain-text message.
Attached image selected block
This shows how I select the block to be rewrapped.
Attached image 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.
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.
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.
Bug 234029 a duplicate?
You need to log in before you can comment on or make changes to this bug.