57477 - Moving text from one <LI> to another <LI> does the wrong thing

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect, P3)

Description

[Kevin McCluskey (gone)]

To reproduce:

1. load the attachment in composer
2. select the <Move under heading1> text
3. ctrl-c to copy to clipboard
4. Click on the <LI> under heading1
5. ctrl-v to paste

Expected:
The selected text should be pasted next to the heading 1 list item.
<this is what happens in 4.x>

What happens:
The selected text is placed in a new nested <LI> underneath the first heading.


If you load the attachment into composer


This is a bug that I run into every week when preparing my status report.

The test case was built using N6-composer.

Comment 1

[Kevin McCluskey (gone)]

Attachment: html file to load into composer

Comment 2

[Kevin McCluskey (gone)]

This bug makes it difficult to produce my weekly status report. I normally copy
and paste items from emails into my status template which contains pre-existing
<LI>'s.

Comment 3

[Kevin McCluskey (gone)]

The following is the result of saving the file after doing the paste.

heading1<br>
<ul>
  <li>
    <ul>
      <li>Move under heading1</li>
    </ul>
    <br>
  </li>
</ul>
<br>
heading2<br>
<ul>
  <li>Move under heading1</li>
</ul>

A <ul> and <li> have been placed around the outside of the text that was pasted.
I tried various ways of selecting the text. Triple clicking/ dragging from
right, dragging from the left, they all yield the same results.

I am using branch build 2000102008.

Comment 4

[rubydoo123]

trible click will select the text and surrounding element structure, dbl-click
selects just the text, but just in case something else is going on here, asking
joe to take a look

Comment 5

[Joe Francis]

This is actually working as designed (beleive it or not!).  When you copy, we 
have no way to know if you mean to copy the text, the li, or the ul.  Our 
strategy is to copy the outmost element for which all the children are selected.  
This may seem wrong here but if you had a three item list and selected across all 
three items it would suddenly seem very right.  

Even though I think the copy behavior is correct, that doesn't mean we shouldn't 
change the paste behavior.  Probably most users would prefer that lists get 
merged into other lists on paste, rather than sublisted.  I'm going to give that 
I try and see what folks think.

cc'ing a random assortment of others to get comments.

Comment 6

[Joe Francis]

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

Comment 7

[Akkana Peck]

In case anyone needs a workaround for now: note Joe's comment about *all* the
children being selected.  If you omit one character at the beginning or end of
the selected text, then it won't include the parent.  You'll have to type that
one character again, of course.

Adding Lisa because she asked me a similar question (or filed a bug, I forget
which) recently and may want to track this if the behavior changes.

Comment 8

[lchiang]

Yes, I was confused when this happened to me.  The workaround was fine for me.
I just could not figure out how to copy text only from a table cell without
having the entire table cell being pasted!

Comment 9

[Joe Francis]

hmmm.  no one ever gave me comments on my proposal.  adding charlie, since he is
always good for a good comment!

Comment 10

[Akkana Peck]

I'll comment: the current behavior seems better than the opposite, of not
copying the enclosing structure (we got more complaints when we did that, and
that's why we made it work this way).

However, we could be even smarter, e.g. paste could notice that it contains only
list items, and is being pasted into an empty list item (is that pretty much
what's happening here?) and merge the pasted list items into the existing list.
 That might be a step toward doing what most users expect (and if the user
really did want a sublist, it would be easy to create one then paste into that
empty list item, or highlight the desired sublist items and click indent).

Being that smart sounds like it might be a lot of work, though, and probably not
a high priority.

Comment 11

[Charles Manske]

While I agree with Joe that we should copy parent block elements, such as LI and
OL, when the all of list item is selected. There are cases, such as pasting
into an existing list, where pasting should insert a new list item (merged into
the destination list, thus the OL in the copy source is ignored.)
In cases where you paste into a non-list block, it seems to me that you
shouldn't paste the LI and OL.

Comment 12

[Joe Francis]

moving a bunch of 0.9 bugs to 0.9.1

Comment 13

[Joe Francis]

this behavior is intentional.  Beth will add a dependency on another bug 
momentarily, for giving the user choice at copy time.

Comment 14

[Kathleen :Brade]

From a usability standpoint, I see two things that would make this less of an 
issue for users:
 * pasting being smarter (notice that an li is being inserting into an li and 
insert them relative to the current levels, not increasing levels)
 * making the increase/decrease of margins work correctly for lists as well as 
blockquotes (this would allow users to easily remove extra list levels).

This second issue isn't really the same as this bug and should be covered in an 
existing bug or filed as a new bug.

Comment 15

[Joe Francis]

Attachment: diffs of editor/bsae

Comment 16

[Joe Francis]

attached a patch that fixes this (additional pasting smarts for lists).

Comment 17

[Kathleen :Brade]

r=brade
note: this also seems to fix bug #66579 so I'm adding the dependency

Comment 18

[Joe Francis]

Attachment: updated diffs to fix errors

Comment 19

[Kathleen :Brade]

I have tested the latest patch (6/13/01); it works very well.  r=brade

Comment 20

[Joe Francis]

kin just sr'd this for me, modulo sme changes he requested which I will make.

Comment 21

[Asa Dotzler [:asa]]

a= [e-mail] for checkin to the trunk.
(on behalf of drivers)

Comment 22

[Joe Francis]

fix checked in

Comment 23

[sujay]

this is fixed, however, after performing step 5) we add an extra
bullet. I don't like this behavior.

Beth has sent Joe a note on this, I might file a bug.

but I will mark this bug verified-fixed because it is a different issue
which is fixed.