112167 - [PATCH]copy/paste within an ordered list prevents correct editing

Status: VERIFIED FIXED

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

Description

[TucsonTester1]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.6+)
Gecko/20011126 Netscape6/6.1b1
BuildID:    20011126

When making an ordered list and copying a whole line of text from one item in
the list, and pasting it to the nth item in the list, composer automatically
creates list item of n+1, which does not go away when pressing the backspace key.

Reproducible: Always
Steps to Reproduce:
1. Launch Composer.
2. Click either bulleted or numbered list button in the toolbar.
3. Enter a line of text.  Press enter.
4. Enter a second line of text.  Press enter
5. Highlight the entire second line of text.  From 'Edit' menu, choose 'Copy.'
6. Click to place cursor on the third line.  From 'Edit' menu, choose 'Paste.'
7. Press 'Backspace.'

Actual Results:  After pressing 'Backspace,' the cursor moves back to the second
line, however the third bullet remains.

Expected Results:  When pressing 'Backspace,' whatever is before the cursor
should be deleted.  The third bullet should have been deleted.

Notes:
This only happens when copy/pasting the entire line of text from a list item. 
Copying a portion of a line works correctly.

When viewing in Show Tag mode, the problem appears to come from the cursor in
the last line of the list being placed before the LI tag.

Comment 1

[Syd Logan]

Since this is list editing (which is important to try and get right, given how
commonly it is used) and given that it behaves differently due to the kind of
content pasted, and that if you click back on that line, *then* hit backspace,
you get different behaviour (it now works), it is no doubt to me that this falls
into the category of confusing behaviour for a common feature. So, marking
EDITORBASE. Assigning to joe since my senses tell me this is rules-related.

Comment 2

[Joe Francis]

I was a bit confused by this report until I realized that you  meant to write 
"third line" instead of "second line" in the Actual Results section.  

Comment 3

[Syd Logan]

WORKSFORME, please verify

Comment 4

[TucsonTester1]

Still seeing the problem using 2001121703 under Win 2k.

Comment 5

[Joe Francis]

I can repro this syd.  Sorry I didn't make that clerar before.

Comment 6

[Joe Francis]

pushing off 098 to 099

Comment 7

[Syd Logan]

lists, plussing

Comment 8

[Joe Francis]

I believe this is fixed by earlier work i did.  

Comment 9

[sujay]

Tucson, please verify...

Comment 10

[michael wendell]

I am still seeing this problem on Win ME using build 2002021108.

One thing to note is that this problem only happens if part the <LI> is in the
selection.  The best way to make sure this gets selected is to double click on
the line:

1. Launch Composer
2. Click on the unnumbered list button on the toolbar
3. Type the word "first" and click enter
4. Type the word "second" and click enter
5. Double click on the word "second" to highlight it
6. Copy it to the clipboard (CTLR - C)
7. Click on the third line and paste the text (CTRL - V)
8. Notice that another bullet is added

If you try to delete this bullet, the caret jumps up to the previously pasted
line and deletes the last character.  But if you change to Show All Tags view,
you see that the caret is actually located between the bullet and the <li> tag.

I am reopening this bug.

Comment 11

[Joe Francis]

ah, ok, i see

Comment 12

[Joe Francis]

099 to 1.0; set pri to 1 for these pushed off EB+ bugs

Comment 13

[Joe Francis]

fixed by revised patch to 99089, coming soon

Comment 14

[Joe Francis]

Attachment: first rev patch - not done

There are some known bugs here.  Just using bugzilla to backup my work for now.

Comment 15

[Kevin McCluskey (gone)]

adt2

Comment 16

[Joe Francis]

Attachment: second rev patch - not done yet

again using bugzilla to cache work-in-progress

Comment 17

[Joe Francis]

Attachment: final patch candidate

I recently had to add some stuff to this patch to deal with invisible breaks
that are at the paste boundary.  ready for reviews.  note that this patch also
includes a small patch from another bug to fix list making across table cells.

Comment 18

[Joe Francis]

I made the improvements kin wanted, plus added code to not put sel inside table
when you paste table.  Fix landed on trunk.

Comment 19

[michael wendell]

Verified on the 05-14 trunk build.

Comment 20

[Kevin McCluskey (gone)]

adt1.0.0

Comment 21

[Jaime Rodriguez, Jr.]

ok, this one doesn't have any reviews. how did this one land on the trunk?

removing adt1.0.0, until the final patch candidate recieves a r/sr=.

Comment 22

[Joe Francis]

This was sr'd by kin in person.  You are right about the r= though.  I had 
thought brade had, but that was a different bug.

Comment 23

[Joe Francis]

Comment on attachment 81476 [details] [diff] [review]
final patch candidate

sr=kin

Comment 24

[Kevin McCluskey (gone)]

nsbeta1-. The fix is too risky for the 1.0 branch.