Closed Bug 70698 Opened 23 years ago Closed 17 years ago

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

Categories

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

defect

Tracking

()

RESOLVED FIXED

People

(Reporter: mar_garina, Assigned: MatsPalmgren_bugz)

References

()

Details

(Keywords: dataloss, hang, regression, Whiteboard: [behavior])

Attachments

(1 file, 2 obsolete files)

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....
Assignee: rods → pchen
Status: UNCONFIRMED → NEW
Component: HTML Form Controls → XP Apps
Ever confirmed: true
Keywords: regression
QA Contact: bsharma → sairuh
Also please change platform 'All', it happens in windows (on drag and drop) as well.
Hardware: PC → All
QA Contact: sairuh → tpreston
Per mar garina's comments, changing to all
OS: Linux → 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 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
reopening.  They may be related, but I doubt it.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Assignee: pchen → kin
Status: REOPENED → NEW
Component: XP Apps → Editor
QA Contact: tpreston → sujay
Summary: Pasting _ON_ TEXTAREA's scrolling arrows produces something weird → Pasting _ON_ TEXTAREA or Composer scrollbar controls draws text
Target Milestone: --- → mozilla1.0
-->kin
*** Bug 82513 has been marked as a duplicate of this bug. ***
Whiteboard: [behavior]
*** 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.
Target Milestone: mozilla1.0 → mozilla1.0.1
*** 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. ***
Priority: -- → P3
Target Milestone: mozilla1.0.1 → Future
*** 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.
Severity: normal → critical
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
Keywords: hang
updating summary to what this bug is actually about (bug 82513)
Summary: Pasting _ON_ TEXTAREA or Composer scrollbar controls draws text → middle mouse click on scrollbar in Composer will paste
(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. ***
Assignee: kinmoz → mats.palmgren
Summary: middle mouse click on scrollbar in Composer will paste → [FIX] middle mouse click on scrollbar in Composer will paste
Target Milestone: Future → ---
Attached patch Patch rev. 1 (obsolete) — Splinter Review
Attached patch Patch rev. 1 (diff -w) (obsolete) — Splinter Review
Attachment #194926 - Flags: superreview?(bzbarsky)
Attachment #194926 - Flags: review?(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?
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.
Attachment #194926 - Attachment is obsolete: true
Attachment #194926 - Flags: superreview?(bzbarsky)
Attachment #194926 - Flags: review?(bzbarsky)
Attached patch Patch rev. 2Splinter Review
Attachment #194925 - Attachment is obsolete: true
Attachment #196263 - Flags: superreview?(bzbarsky)
Attachment #196263 - Flags: review?(bzbarsky)
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.
Attachment #196263 - Flags: superreview?(bzbarsky)
Attachment #196263 - Flags: superreview+
Attachment #196263 - Flags: review?(bzbarsky)
Attachment #196263 - Flags: review+
*** 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.
QA Contact: sujay → editor
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.
Attachment #196263 - Flags: approval1.8.1.4?
Attachment #196263 - Flags: approval1.8.0.12?
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.
Attachment #196263 - Flags: approval1.8.1.4?
Attachment #196263 - Flags: approval1.8.1.4-
Attachment #196263 - Flags: approval1.8.0.12?
Attachment #196263 - Flags: approval1.8.0.12-
Fixed a long time ago.  The remaining question was native scrollbar on
MacOSX, but that has been removed on trunk now.
Status: NEW → RESOLVED
Closed: 23 years ago17 years ago
Resolution: --- → FIXED
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). 
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: