Closed Bug 600570 Opened 14 years ago Closed 14 years ago

textarea: cut and paste broken, pastes more than cut, leaves selectionEnd with wrong value

Categories

(Core :: DOM: Editor, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla2.0b7
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: kdevel, Assigned: ehsan.akhgari)

References

Details

(Keywords: regression)

Attachments

(2 files)

User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b7pre) Gecko/20100101 Firefox/4.0b7pre Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b7pre) Gecko/20100101 Firefox/4.0b7pre 1. Paste (Ctrl-V) pastes more than was cut (Ctrl-X). 2. subsequent select leads to wrong value of selectionEnd Reproducible: Always Steps to Reproduce: 1. place cursor in front of first 'a' 2. select the three a's plus the newline (shift plus four times cursor right) 3. cut (ctrl-x) 3. place cursor in front of first 'b' (cursor right) 4. paste (ctrl-v) 5. select alls of the textarea's content 6. press 'check selection' Actual Results: full text = <[aaa bbb]> length of full text = 9 selection start = 0 selection end = 5 (start <= end) = true selected text = <[aaa > Expected Results: full text = <[aaa bbb]> length of full text = 9 selection start = 0 selection end = 9 (start <= end) = true selected text = <[aaa bbb]> There is a blank line between the first ('[aaa') and the third ('bbb]'). No such line is shown with FF 3.5.11 and other not so recent versions of MF.
Attached file testcase
>hg bisect -g The first bad revision is: changeset: 53726:c611f052ec92 user: Ehsan Akhgari <ehsan@mozilla.com> date: Sun Jul 11 16:26:26 2010 -0400 summary: Bug 240933 - Part 1: Do not split multiline text into textframes separated by BR elements; r=roc a=dbaron
This revision produces the additional line and the following output: full text = <[aaa bbb]> length of full text = 9 selection start = 0 selection end = 10 (start <= end) = true selected text = <[aaa bbb]>
Confirming. Mozilla/5.0 (Windows NT 5.0; rv:2.0b7pre) Gecko/20101005 Firefox/4.0b7pre [I am also seeing something similar to this but I haven't worked out if it is this or another bug - so I am still investigating]
Blocks: 240933
Status: UNCONFIRMED → NEW
Component: General → Editor
Ever confirmed: true
OS: Linux → All
Product: Firefox → Core
QA Contact: general → editor
Hardware: x86_64 → All
Version: unspecified → Trunk
Keywords: regression
(In reply to comment #4) > [I am also seeing something similar to this but I haven't worked out if it is > this or another bug - so I am still investigating] I am seeing an extra blank line on paste so is part of this bug.
CCing bz and dbaron because they had told me that they had seen cut && paste related weirdness in textareas recently.
Assignee: nobody → ehsan
Status: NEW → ASSIGNED
blocking2.0: --- → ?
Yeah, and in fact I'd finally come up with steps to reproduce my issue: 1) Type "aaa" on the first line of a textarea. 2) Leave a blank line. 3) Type "bbb" on the third line of a textarea. 4) Position your caret on the blank line between "aaa" and "bbb" 5) Select an entire line (including trailing newline) in my xterm 6) Paste that into the textarea at the position from step 4 After this I see two blank lines between the end of the paste and "bbb". And if I delete one of them, there is no blank line in the submitted text. Setting final+, but the earlier we fix the fewer broken bugzilla comments... ;)
blocking2.0: ? → final+
(In reply to comment #7) > Yeah, and in fact I'd finally come up with steps to reproduce my issue: > 1) Type "aaa" on the first line of a textarea. > 2) Leave a blank line. > 3) Type "bbb" on the third line of a textarea. > 4) Position your caret on the blank line between "aaa" and "bbb" > 5) Select an entire line (including trailing newline) in my xterm > 6) Paste that into the textarea at the position from step 4 > > After this I see two blank lines between the end of the paste and "bbb". And > if I delete one of them, there is no blank line in the submitted text. Great, I'll look into this tomorrow. > Setting final+, but the earlier we fix the fewer broken bugzilla comments... ;) Hmm, in fact, I'm not sure I'm in favor of that decision... I'd really like beta coverage on this, as it's a pretty major breakage, and I'm not sure yet what the fix would look like. Is there any particular reason you set this to block final? If not, I'd like to ask you to reconsider it for betaN.
> Is there any particular reason you set this to block final? Nothing other than not wanting to overload you for the betas. ;)
blocking2.0: final+ → betaN+
(In reply to comment #9) > > Is there any particular reason you set this to block final? > > Nothing other than not wanting to overload you for the betas. ;) More work only makes me happier (albeit dizzier)! :-)
OK, what's happening here is that we're injecting a BR node in the textarea's anonymous DIV when pasting. This is what the frame tree looks like after pasting: http://pastebin.mozilla.org/808378
Attached patch Patch (v1)Splinter Review
So, this bug is coming from my first patch in bug 240933. I basically added this code to work around some caret positioning problems, which I later addressed in my other patches on that bug. But apparently I forgot to take this code out in the end, and indeed it's the wrong thing to do even as a caret positioning hack.
Attachment #481359 - Flags: review?(bzbarsky)
Comment on attachment 481359 [details] [diff] [review] Patch (v1) r=me; I like patches with minuses in them. ;)
Attachment #481359 - Flags: review?(bzbarsky) → review+
Whiteboard: [needs landing]
Works. Also for Bug 600803
Blocks: 600803
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [needs landing]
Target Milestone: --- → mozilla2.0b8
Target Milestone: mozilla2.0b8 → mozilla2.0b7
Keywords: verifyme
mass remove verifyme requests greater than 4 months old
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: