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.
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.
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.
WORKSFORME, please verify
Still seeing the problem using 2001121703 under Win 2k.
I can repro this syd. Sorry I didn't make that clerar before.
pushing off 098 to 099
I believe this is fixed by earlier work i did.
Tucson, please verify...
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.
ah, ok, i see
099 to 1.0; set pri to 1 for these pushed off EB+ bugs
fixed by revised patch to 99089, coming soon
Created attachment 75296 [details] [diff] [review] first rev patch - not done There are some known bugs here. Just using bugzilla to backup my work for now.
Created attachment 79952 [details] [diff] [review] second rev patch - not done yet again using bugzilla to cache work-in-progress
Created attachment 81476 [details] [diff] [review] 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.
I made the improvements kin wanted, plus added code to not put sel inside table when you paste table. Fix landed on trunk.
Verified on the 05-14 trunk build.
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=.
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 on attachment 81476 [details] [diff] [review] final patch candidate sr=kin
nsbeta1-. The fix is too risky for the 1.0 branch.