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.

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....

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

Per mar garina's comments, changing to all

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 ***

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

-->kin

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

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

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

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

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

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.

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

(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?

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

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

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?

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)

(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 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 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.

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

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

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 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

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

(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.

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. - bugzilla@broadpark.no

This bug is also present in Thunderbird 1.0.7.

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

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

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 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 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.

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

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

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

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).