48786 - Middle click pasting in textfield inserts at wrong point within field

Status: VERIFIED DUPLICATE of bug 57913

(Core :: DOM: Editor, defect, P3)

Description

[Paul McGarry]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.15 i686; en-US; m18) Gecko/20000812
BuildID:    2000081209

Pasting into a textfield with the middle mouse button often results in the text
being pasted into the line above where you want it.


Reproducible: Always
Steps to Reproduce:
1.Enter a longish line of text in a textfield ('This is a fairly long line')
2.Hit enter and enter a small amount of text in the next line ('Short bit')
3.Select some text from a terminal window ('Pasted text')
4.Position the pointer just after the 'Short bit') in the textfield
5.Paste with middle click of mouse


Actual Results:
This is a fPasted textairly long line
Short bit

Expected Results:
This is a fairly long line
Short bit Pasted text

Comment 1

[John Morrison]

Actually, I can't reproduce this. Sujay: known problem? Can you see this?

Comment 2

[rubydoo123]

on win98, I can't reproduce this either, Sujay, can you please test this on 
linux and mac

Comment 3

[Paul McGarry]

Just letting you know that this still happens consistantly for me.
Linux, 2000081320
To recap (in case I wasn't clear before).
1)Type a line of stuff in a textfield
2)Hit enter at the end of the line
3)Use your mouse to select some text from another window (eg a terminal).
4)Reposition your mouse pointer on the empty line (so it looks like a pointer,
not an I beam) and click the middle button to paste.

Note that I am not left clicking anywhere in the text box between steps 3 and 4.
The flashing cursor is still at the beginning of the blank line from step 2. I
am using 'Focus follows pointer' in X.

Note that this is specifically to do with the type of pasting typically achieved
with a single click of the middle mouse button under X on linux and is probably
completely unrelated to right-click paste or click-menubar-paste under other OSs
that don't use X (or using those methods on OSs that do also cater for
middle-click pasting).

Comment 4

[Paul McGarry]

And by 'textfield' I in fact mean an html textarea in a form in case that was
adding any confusion.

Comment 5

[R.K.Aa.]

confirming this bug. It's annoyed me for ages.

Best step to repro is to write several lines (5...6) (with linefeeds) for
instance in a comment form like this.
Then copy some text by only selecting it
It is now on X clipboard
Then write one more line in comment
When you now middle click to paste, the paste is inserted whereever the
arrow-cursor is positioned, and NOT (as expected) where the blinking insertion
point is.

This bug has  been commented on in a few other bugs i've seen, but i haven't
seen it filed as a separate bug.

Tested w/M18 linux 081420

Comment 6

[sujay]

I can't reproduce this.....

Comment 7

[rubydoo123]

asking kin if he can reproduce this one.

Comment 8

[kinmoz]

Accepting bug.

Comment 9

[rubydoo123]

reporter: is this still an issue, can you try this again using a recent build
kin: can you dup this?

Comment 10

[Paul McGarry]

This is still a problem for me 2000091908.

Comment 11

[R.K.Aa.]

*** Bug 55505 has been marked as a duplicate of this bug. ***

Comment 12

[R.K.Aa.]

the problem seems to be that a middle-mouse click also sets a new insertion
point, instead of honoring existing position of caret.

Comment 13

[Paul McGarry]

No, no, (imho) no! Middle clicking should set the insertion point (that is the
way it behaves in every other app I've ever used).
The problem is that Moz isn't setting the insertion point to the correct place.
I am going to attach 3 pngs, one which marks where I am about to click, the next
is the (bad) result gained from that click and the third shows where I think the
pasted text should turn up (which I did manually, without pasting).

Comment 14

[Paul McGarry]

Attachment: Picture showing where I am about to paste

Comment 15

[Paul McGarry]

Attachment: Picture showing results of paste

Comment 16

[Paul McGarry]

Attachment: Picture showing expected results

Comment 17

[rubydoo123]

future

Comment 18

[Scott Gifford (old account)]

*** Bug 58707 has been marked as a duplicate of this bug. ***

Comment 19

[Scott Gifford (old account)]

I am able to see this bug consistently in a CVS build from 10/31/2000 on
PC/Linux; I've seen it at least since M17.  It's really annoying.

This bug is marked [need info]; what info is needed?

BTW, I suspect this may be related to bug #53610.

Comment 20

[Scott Gifford (old account)]

I'm still seeing incorrect (although slightly different) behavior when I follow
the initial reporter's instructions.  I now see the text being inserted after
'This is a fairly long line' instead of in the middle of it.

I notice that if I right-click slightly lower than I normally would, the paste
will often go to the right spot.  However, if I left-click there, the cursor is
positioned correctly.  Strange.

Comment 21

[Scott Gifford (old account)]

FYI, still seeing this bug on 2001032614.

Comment 22

[R.K.Aa.]

*** Bug 88374 has been marked as a duplicate of this bug. ***

Comment 23

[Francisco León]

*** Bug 88805 has been marked as a duplicate of this bug. ***

Comment 24

[Francisco León]

*** Bug 70698 has been marked as a duplicate of this bug. ***

Comment 25

[Jesse Ruderman]

See also bug 82826, reported imagemap coords wrong if middle-clicked.

Comment 26

[Jesse Ruderman]

See also bug 57913, textarea pasting [with middle mouse button] into the middle
of blank lines is wonky.

Comment 27

[rubydoo123]

*** This bug has been marked as a duplicate of 57913 ***

Comment 28

[sujay]

v