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

VERIFIED FIXED in mozilla1.0

Status

()

Core
Editor
P1
normal
VERIFIED FIXED
16 years ago
16 years ago

People

(Reporter: TucsonTester1, Assigned: Joe Francis)

Tracking

Trunk
mozilla1.0
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

16 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.

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

16 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
(Assignee)

Comment 2

16 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.  

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

Comment 3

16 years ago
WORKSFORME, please verify
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Priority: -- → P1
Resolution: --- → WORKSFORME
(Reporter)

Comment 4

16 years ago
Still seeing the problem using 2001121703 under Win 2k.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(Assignee)

Comment 5

16 years ago
I can repro this syd.  Sorry I didn't make that clerar before.
(Assignee)

Comment 6

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

Comment 7

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

Updated

16 years ago
Keywords: nsbeta1+
(Assignee)

Comment 8

16 years ago
I believe this is fixed by earlier work i did.  
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED

Comment 9

16 years ago
Tucson, please verify...

Updated

16 years ago
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 10

16 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.
(Assignee)

Comment 11

16 years ago
ah, ok, i see
Status: REOPENED → ASSIGNED
(Assignee)

Comment 12

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

Comment 13

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

Comment 14

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

Updated

16 years ago
Component: Editor: Composer → Editor: Core

Updated

16 years ago
Summary: copy/paste within an ordered list prevents correct editing → [PATCH]copy/paste within an ordered list prevents correct editing
(Assignee)

Comment 16

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

again using bugzilla to cache work-in-progress
(Assignee)

Comment 17

16 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
(Assignee)

Comment 18

16 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.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED

Comment 19

16 years ago
Verified on the 05-14 trunk build.
Status: RESOLVED → VERIFIED
adt1.0.0
Keywords: adt1.0.0

Comment 21

16 years ago
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
(Assignee)

Comment 22

16 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]
(Assignee)

Comment 23

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

sr=kin
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.