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

VERIFIED FIXED in mozilla1.0



18 years ago
17 years ago


(Reporter: TucsonTester1, Assigned: mozeditor)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: EDITORBASE+; FIXINHAND; need r=;a= [adt2])


(1 attachment, 2 obsolete attachments)



18 years ago
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.

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

17 years ago
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.
Assignee: syd → jfrancis
OS: Windows XP → All
Hardware: PC → All
Whiteboard: EDITORBASE

Comment 2

17 years ago
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.  

Ever confirmed: true
Whiteboard: EDITORBASE → EDITORBASE; 1 day
Target Milestone: --- → mozilla0.9.8

Comment 3

17 years ago
WORKSFORME, please verify
Last Resolved: 17 years ago
Priority: -- → P1
Resolution: --- → WORKSFORME

Comment 4

17 years ago
Still seeing the problem using 2001121703 under Win 2k.
Resolution: WORKSFORME → ---

Comment 5

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

Comment 6

17 years ago
pushing off 098 to 099
Target Milestone: mozilla0.9.8 → mozilla0.9.9

Comment 7

17 years ago
lists, plussing
Whiteboard: EDITORBASE; 1 day → EDITORBASE+; 1 day


17 years ago
Keywords: nsbeta1+

Comment 8

17 years ago
I believe this is fixed by earlier work i did.  
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 9

17 years ago
Tucson, please verify...


17 years ago
Resolution: FIXED → ---

Comment 10

17 years ago
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

17 years ago
ah, ok, i see

Comment 12

17 years ago
099 to 1.0; set pri to 1 for these pushed off EB+ bugs
Target Milestone: mozilla0.9.9 → mozilla1.0

Comment 13

17 years ago
fixed by revised patch to 99089, coming soon
Whiteboard: EDITORBASE+; 1 day → EDITORBASE+; FIXINHAND; need r=;sr=;a=

Comment 14

17 years ago
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.
Whiteboard: EDITORBASE+; FIXINHAND; need r=;sr=;a= → EDITORBASE+; FIXINHAND; need r=;sr=;a= [adt2]


17 years ago
Component: Editor: Composer → Editor: Core
Summary: copy/paste within an ordered list prevents correct editing → [PATCH]copy/paste within an ordered list prevents correct editing

Comment 16

17 years ago
Created attachment 79952 [details] [diff] [review]
second rev patch - not done yet

again using bugzilla to cache work-in-progress

Comment 17

17 years ago
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.
Attachment #79952 - Attachment is obsolete: true

Comment 18

17 years ago
I made the improvements kin wanted, plus added code to not put sel inside table
when you paste table.  Fix landed on trunk.
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 19

17 years ago
Verified on the 05-14 trunk build.
Keywords: adt1.0.0
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=.
Keywords: adt1.0.0

Comment 22

17 years ago
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.
Whiteboard: EDITORBASE+; FIXINHAND; need r=;sr=;a= [adt2] → EDITORBASE+; FIXINHAND; need r=;a= [adt2]

Comment 23

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

Attachment #81476 - Flags: superreview+
nsbeta1-. The fix is too risky for the 1.0 branch.
Keywords: nsbeta1+ → nsbeta1-
You need to log in before you can comment on or make changes to this bug.