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

RESOLVED FIXED in mozilla2.0b7

Status

()

RESOLVED FIXED
8 years ago
5 years ago

People

(Reporter: kdevel, Assigned: Ehsan)

Tracking

({regression})

Trunk
mozilla2.0b7
regression
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(blocking2.0 betaN+)

Details

Attachments

(2 attachments)

(Reporter)

Description

8 years ago
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.
(Reporter)

Comment 1

8 years ago
Created attachment 479413 [details]
testcase
(Reporter)

Comment 2

8 years ago
>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
(Reporter)

Comment 3

8 years ago
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]>

Comment 4

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

Updated

8 years ago
Keywords: regression

Comment 5

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

Comment 6

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

Comment 8

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

Comment 10

8 years ago
(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)!  :-)
(Assignee)

Comment 11

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

Comment 12

8 years ago
Created attachment 481359 [details] [diff] [review]
Patch (v1)

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

Updated

8 years ago
Whiteboard: [needs landing]
(Reporter)

Comment 14

8 years ago
Works. Also for Bug 600803
(Assignee)

Comment 15

8 years ago
http://hg.mozilla.org/mozilla-central/rev/1ffa0495b021
Status: ASSIGNED → RESOLVED
Last Resolved: 8 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.