191603 - When clicking in a form's textarea/input, the text inside that area is copied to the copy buffer

Status: NEW

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

Description

[Anoakie Turner]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9

When clicking in a form's textarea or input field, the string:
javascript:this.form.elements['name'].select(); will scribble over your copy
buffer if you are using Linux.  I have verified this in both WindowMaker and
KDE, so I don't think it's a window manager problem.

Reproducible: Always

Steps to Reproduce:
Steps to reproduce:
1) Visit http://www.darkpact.com/test4.html
2) Click on the textarea's scrollbar
3) Middle-click paste into another window to see what is in your copy buffer.
   If everything went according to my dark, devious plans, it should be the 
   text that is featured inside of the textarea!
4) You can also reproduce this bug by clicking on the text in the textarea, or
   on the input field to the right of the text area.
Actual Results:  
The copy buffer is filled with the text from the field.

Expected Results:  
NOTHING! :)  I really don't like my copy buffer being smashed by Javascript... 
Especially when scrolling though a textarea with scrollbars!

This bug is probably only applicable to operating systems that have a
highlight-copy mechanism.

Comment 1

[R.K.Aa.]

I can't remember seeing that before. Do you have a live site sample?
I can think of times i would find it useful, though.

Comment 2

[Anoakie Turner]

I can't show you anything that is live, but I do know one project that uses it.
 PHPMyAdmin (http://phpmyadmin.sourceforge.net/)  The onfocus highlight/copy bug
is REALLY annoying when trying to middle-click paste into a text area.  When you
middle click paste, it will activate the 'onfocus' before performing the paste,
so it will smash your copy buffer and repaste the text from the textarea.

Comment 3

[Anoakie Turner]

Here is a textual example (so you don't have to veiw the source on the website:

<form>
<textarea name="test" onfocus="javascript:this.form.elements['test'].select();">
Text that will be copied.
</textarea>
</form>

Comment 4

[Andrew Schultz]

Attachment: testcase

Comment 5

[Boris Zbarsky [:bzbarsky]]

kin, I thought you fixed this in bug 188440?  Looks like you only got the cases
when _we_ select the text, not the ones where the _website_ does.... 

(marking dataloss, since this wipes out the clipboard unexpectedly).

Comment 6

[Boris Zbarsky [:bzbarsky]]

To kin.

kin, could you please check this out?

Comment 7

[kinmoz]

bz, I think this is a dup of bug 188440. The build date used by the Anoakie is
2002-12-26, and I didn't fix bug 188440 until 2003-01-21.

Anoakie, can you try a more a recent build?

I did verify, in my TRUNK build, that the select() call in the test case
triggers SelectAllContents() which was part of the fix for 188440, so it does
look like a dup.

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

Comment 8

[Boris Zbarsky [:bzbarsky]]

kin, give me _some_ credit.

1)  2002-12-26 is before 2003-01-08, which is when bug 88049 was checked in,
    causing bug 188440
2)  The problem with the testcase in this bug is quite present in linux trunk
    build 2003-02-01-22.  Perhaps I should have clarified that this is a problem
    with builds with the fix for bug 188440 in them.

So this problem is distinct from that of bug 188440 (and predates it).  But it's
certainly related; I'm surprised we're using a different codepatch in this
case....  (Do we perhaps call SelectAllContents() and then _also_ call some
other selection function?)

Do you have access to a Linux build to debug with usefully, or should I try to
see who's asserting PRIMARY?

Comment 9

[Anoakie Turner]

I just gave 20030130 a whirl (mozilla-snapshot in debian unstable), and it
exhibits the same problems as my 20021226 build.  I also download the latest
nightly (20030203), and it too shows this problem.  Not as severe as the
20021226 build (scrolling with the scrollbars no longer smashes the copy
buffer), but when you click in the text area, it will still smash the copy
buffer.  I think you should give this bug another try with the latest build
before marking it as 'RESOLVED'.
And I got a midair collision...  It seems that someone else has reopened it. 
Thanks :)

Comment 10

[kinmoz]

Sorry for the pre-mature dup'ing bz.

It looks like the problem is due to the fact that the AutoCopy code is looking
for a selection change that is the result of a button up event. The problem with
this test case is that the order of events happen like this:

  1. Button Down (Selection is collapsed at point clicked)
  2. A focus event is synthesized and processed synchronously (while post
processing the Button Down event) which triggers the JS select() call in the
testcase, causing all of the content in the widget to be selected.
  3. The user releases the button and the auto copy code is triggered.

Note, I am actually testing this on Win32 since I don't have a Linux build
currently, but I imagine the same set of events happen on Linux too.

Comment 11

[John Keiser (jkeiser)]

Events aren't really the problem.  Everything appears to be happening in the
proper order, it's just that autocopy isn't checking whether the selection that
was created is the result of a user input or not.  As we talked about, I'd
suggest having the place where mousemoves (and arrow keys) trigger selection set
a boolean noting that the selection is the result of user interaction.

Comment 12

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.