70698 - [FIX] middle mouse click on scrollbar in Composer will paste

Status: RESOLVED FIXED

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

Description

[mar_garina]

Description:
Pasting text from clipboard (by middle / right+left mouse buttons, under X), or
just DROPPING dragged text, _ON_ the arrows of the <TEXTAREA> control, causes
mozilla to print the dropped/pasted text _OVER_ the arrow itself, or sometimes
just causes it to hide the scrollbar (I think when the text is too long).

How to reproduce:
http://www.deot.net/mozbug.html
Two options:
1. (I think under X only): Select some text (never mind from which window) using
the mouse, then paste it when the mouse is over the scrollbar arrow. usually
done by pressing the middle mouse button or right+left mouse buttons pressed
together.
2. (I believe it happens on all platforms, but not sure): Drag something (for
example bookmarks) and drop them over the arrow of the textarea's scrollbar.

What happens:
Prints the dropped or pasted text over the arrow, or hides the scrollbar.

What should happen:
Mozilla should ignore anything pasted or dropped over the scrollbar's arrows.

Comment 1

[Boris Zbarsky [:bzbarsky]]

I'm seeing this as well.  I tried some older builds, and this bug is _not_
present in 2001-01-28-06, but _is_ present in 2001-01-28-21.  Not really sure
what got checked in in there that could have caused this....

Comment 2

[mar_garina]

Also please change platform 'All', it happens in windows (on drag and drop) as well.

Comment 3

[Terri Preston]

Per mar garina's comments, changing to all

Comment 4

[Francisco León]

I think this is dupe of bug 48786. If you dont agree, send flames to /dev/null
:) and reopen it

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

Comment 5

[Boris Zbarsky [:bzbarsky]]

reopening.  They may be related, but I doubt it.

Comment 6

[Kathleen :Brade]

-->kin

Comment 7

[Kathleen :Brade]

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

Comment 8

[Kathleen :Brade]

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

Comment 9

[kinmoz]

Bulk move of mozilla1.0 bugs to mozilla.1.0.1. I will try to pull some of these
back in if I can.

Comment 10

[Boris Zbarsky [:bzbarsky]]

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

Comment 11

[Boris Zbarsky [:bzbarsky]]

Note bug 36019.  The fix for that should probably be applied here.

Comment 12

[Carey Evans]

I see this when pasting or drag-and-dropping in the trough of the scrollbar, not
the arrow.  When pasting, the textarea does reposition correctly, in addition to
pasting the text.

This is what bug 127576 is reporting, which is slightly different to the
original  bug.

Comment 13

[Boris Zbarsky [:bzbarsky]]

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

Comment 14

[R.K.Aa.]

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

Comment 15

[Andrew Schultz]

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

Comment 16

[R.K.Aa.]

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

Comment 17

[R.K.Aa.]

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

Comment 18

[Kenneth Herron]

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

Comment 19

[Brant Gurganus]

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.

Comment 20

[Boris Zbarsky [:bzbarsky]]

This worksforme now... is anyone still seeing this?

Comment 21

[R.K.Aa.]

To comment 20:
brade resolved bug 82513 as a dup, and I still see that one.

Comment 22

[Boris Zbarsky [:bzbarsky]]

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

Comment 23

[Boris Zbarsky [:bzbarsky]]

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

Comment 24

[Boris Zbarsky [:bzbarsky]]

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

Comment 25

[R.K.Aa.]

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

Comment 26

[Andrew Schultz]

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

Comment 27

[R.K.Aa.]

this can also cause a freeze:

open cnn.com and "edit page".
In composer: shift to html source and select one word
Shift back to normal view and middle mouse click on scrollbar, below slider:
Result: 100% cpu usage and freeze. mozilla-bin process has to be killed to be
used again.

testing with a current CVS build, Linux. Adding hang kw

Comment 28

[R.K.Aa.]

updating summary to what this bug is actually about (bug 82513)

Comment 29

[Akkana Peck]

(Thanks for the clear summary, R.K.Aa)

What I'm seeing: the scrollbar jumps, as expected, but then the paste happens
anyway.

I thought initially that this probably meant that PreventDefault wasn't being
called on the mouse button event.  But I tried a simple fix for that, and when
it didn't work I poked around a bit to find out why, and here's the scoop:

So then I suspected that the scroll was being handled by
nsSliderFrame::MouseDown ... which in fact does not call PreventDefault, but
adding it doesn't help.  The paste is being handled by
nsTextEditorMouseListener::MouseClick (which doesn't check for
GetPreventDefault, but adding that doesn't help either).  See the problem? 
MouseDown is one event, and MouseClick is a different event, so handling the
first doesn't prevent the second from happening.

Moving the editor's middleclick handling from MouseClick to MouseDown cures the
problem, but that's not the right solution: it really should be handled on
click, not down, and I suspect that it's only using mouse down in layout because
it was a convenience since the twips calculation code that handles dragging was
already in that routine.  Anyway, factoring out the relevant code isn't difficult.

Unfortunately, it turns out that nsSliderFrame::MouseDown is not in fact where
the scroll is being handled.  There's probably another routine somewhere that
does the same thing, in the same way, also on MouseDown instead of MouseClick;
and if we could find that routine, we could move it to MouseClick instead. 
Anybody else have better luck with finding this than I'm having?

Comment 30

[Evert Verhellen]

I also see this problem in the Compose window (File > New > Message), not only
in the Composer window.

Comment 31

[R.K.Aa.]

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

Comment 32

[Mats Palmgren (inactive)]

Attachment: Patch rev. 1

Comment 33

[Mats Palmgren (inactive)]

Attachment: Patch rev. 1 (diff -w)

Comment 34

[Boris Zbarsky [:bzbarsky]]

Hmm... So right now preventing the default action of a mouseup does not prevent
the click event?  And this is what's being changed, basically?

Put another way, is there a reason the scrollbar needs to prevent the mouseup,
not the click?

Comment 35

[R.K.Aa.]

I probably don't understand this but just to make sure:
it's the pasting that should be prevented. A mouseup should stop a scroll, which
should be continous while pressed. (see bug 64866)

Comment 36

[Mats Palmgren (inactive)]

(In reply to comment #34)
> Put another way, is there a reason the scrollbar needs to prevent the mouseup,
> not the click?

Not really, I just couldn't get preventdefault="true" to work for "click".
I have found the problem now.

Comment 37

[Mats Palmgren (inactive)]

Attachment: Patch rev. 2

Comment 38

[Kathleen :Brade]

Comment on attachment 196263 [details] [diff] [review]
Patch rev. 2

Can you please fix this comment in nsEditorEventListeners.cpp:
+    //non-ui, or non-trusted event passed in.	bad things.
Add a space after the '//' and remove the ','

Thanks!

Comment 39

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 196263 [details] [diff] [review]
Patch rev. 2

I guess this is ok, but does this also fix native scrollbars?  I don't see how
it does.

Also, things other than the scrollbar could be calling preventDefault on the
event, I think, so I wouldn't mention "scrollbar" explicitly in that comment.

Comment 40

[Adam Guthrie]

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

Comment 41

[Adam Guthrie]

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

Comment 42

[Mats Palmgren (inactive)]

I tried reproducing this on a Mac (which I think uses native scrollbars)
using a three button mouse, but I couldn't get middle-click paste to work.
I'd appreciate if someone on a platform with native scrollbars and is using
middle-click paste could tell me if this bug can be reproduced, thanks.

Comment 43

[Mats Palmgren (inactive)]

Comment on attachment 196263 [details] [diff] [review]
Patch rev. 2

Fixed the code comments as requested in comment 38 and 39.
Checked in to trunk 2005-10-08 03:08 PDT

Comment 44

[Boris Zbarsky [:bzbarsky]]

Josh, Simon, is it possible to get middle-paste working on mac?  And does mac
use native scrollbars (at least in Camino?).

Comment 45

[Asaf Romano (gone)]

(In reply to comment #44)
> is it possible to get middle-paste working on mac?

turning on middlemouse.paste doesn't wfm in latest mac seamonkey.

> And does mac use native scrollbars (at least in Camino?).

As long as the a native theme is used, yes.

Comment 46

[R.K.Aa.]

For Mats Palmgren: Tack! It works like charm (WinXP)

In two days it will be 4 years since I filed bug 82513. It was resolved dup of
this one based on some misunderstanding. Then this one was stuck in a limbo for
years, once the initial issue was gone. Please mail me your address - I'd like
to send you a bottle of champagne if you don't mind. Or the equivalent in SEK if
you prefer (or if "systembolaget" doesn't cooperate..I mailed them for advice)

R.K.Aa. - [e-mail]

Comment 47

[Martin Gerbershagen]

This bug is also present in Thunderbird 1.0.7. 

Comment 48

[zug_treno]

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

Comment 49

[Wayne Mery (:wsmwk)]

mats, is something not finished that the bug wasn't marked fixed after checkin?

Comment 50

[amlai]

Has a patch for this bug been checked in recently?  I still experience the bug on Thunderbird 1.5.0.7.  I've been applying a patch to correct for it and rebuilding the rpms for a while now.  As far as I can tell, the patch lised here has no bad side effects.

Comment 51

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 196263 [details] [diff] [review]
Patch rev. 2

Would like to get this on the branches as a stability fix as it most affects users on platforms with middle click paste, such as *nix.

Comment 52

[Daniel Veditz [:dveditz]]

Comment on attachment 196263 [details] [diff] [review]
Patch rev. 2

Not approved, this patch does not apply to the 1.8 branch. Some of it applied to the 1.8.0 branch. We would need branch-appropriate patches and if they are significantly different they would need re-review before we would grant approval.

Comment 53

[Mats Palmgren (inactive)]

Fixed a long time ago.  The remaining question was native scrollbar on
MacOSX, but that has been removed on trunk now.

Comment 54

[amlai]

Still not fixed.  I just checked w/ Thunderbird 2.0.0.7.  Middle click on the scroll bar area still causes a paste.

Comment 55

[amlai]

Sorry, this was under Linux (CentOS 5), w/ version downloaded directly from mozilla.com.

Comment 56

[Mats Palmgren (inactive)]

It's fixed on _trunk_ which is what the Status field reflects.
We know it's not fixed on branches.  Thunderbird 2.0.0.7 is built
from the 1.8 branch (you can see this in the Help->About Thunderbird as
rv:1.8.1.7).