Closed Bug 53537 Opened 24 years ago Closed 24 years ago

[unix] middle-mouse click on scrollbar loads pasted page

Categories

(Core :: XUL, defect, P2)

x86
Linux
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: burnus, Assigned: bugs)

References

Details

(Keywords: regression, Whiteboard: [rtm++] Fix on trunk)

This is 2000-09-13-12/Linux (as it claims, it is the latest available nightly
and looks newer than 2000-09-19-21 my previous nightly). About shows:
Gecko/20000920.

If you use the middle mouse button click to move the scrollbar to a certain
position and don't click on the bar itself (i.e. on the arrows or the parts wich
aren't covered by the bar), the toolbar scrolls (on the button nothing happens
as supposed).

But: Additionally this link is load or a message box pops up to say that
(current contens of the clipboard) cannot be loaded.

*** This bug has been marked as a duplicate of 52185 ***
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
verified dup of 52185 "middle button click on scrollbar when at ftp-site pastes
clipboard to URL-field"
Status: RESOLVED → VERIFIED
No, this is different than the FTP case. This is for a normal web page in the
browser, and something has broken. The code that normally prevents the paste
when the middlemouse click is on a scrollbar is failing because it now believes 
that 'event.target.localName == "HTML"' which is seriously wrong (it should be 
some element of the scrollbar). 
Status: VERIFIED → UNCONFIRMED
Keywords: nsbeta3
Resolution: DUPLICATE → ---
-> evaughan, for the interim.
... but primarily for why the event.target has become confused.
Assignee: trudelle → evaughan
Status: UNCONFIRMED → NEW
Ever confirmed: true
-> jrgm
Assignee: evaughan → jrgm
*** Bug 53668 has been marked as a duplicate of this bug. ***
This is just fallout from bug 51263. hyatt changed most of the appropriate
calls form event.target to event.originalTarget, but this one was left out. 
One line fix in navigator.js:BrowserHandleMiddleClick()
Keywords: regression
Here's the fix, I do believe: 

Index: navigator.js
===================================================================
RCS file: /cvsroot/mozilla/xpfe/browser/resources/content/navigator.js,v
retrieving revision 1.233
diff -u -r1.233 navigator.js
--- navigator.js        2000/09/20 12:23:49     1.233
+++ navigator.js        2000/09/22 03:22:35
@@ -1562,7 +1562,7 @@
 
   function browserHandleMiddleClick(event)
   {
-    var target = event.target;
+    var target = event.originalTarget;
     if (pref.GetBoolPref("middlemouse.openNewWindow"))
     {
       var node = enclosingLink(target);

Spamming some xheads to see who wants to take ownership of this, because
I don't know nothing about checkins, reviews, supah-reviews, ...
Keywords: patch, rtm
Adding hyatt, don.  If jrgm can't do the checkin,
it shouldn't be on his list.  This is xpapps area,
but it looks like hyatt knows what's going on.
Over to don, who should probably talk with hyatt.
Assignee: jrgm → don
I know what's going on and this is the correct fix. Hyatt posted to .xpfe 
earlier. r=alecf
Assignee: don → hyatt
Whiteboard: [rtm+]
Marking "rtm+" and re-assinging to hyatt so he can apply John Morrison's fix
that's been reviewed by alecf.  I recommend we get this fixed on the trunk now.

Peter and David, do you want to make this "nsbeta3+" and try to get it into the
branch sooner?
XpApps issue.

--> Reassigning to ben.
Assignee: hyatt → ben
SR = myself. I've applied this patch in my tree and will check in to the trunk 
asap. 
Status: NEW → ASSIGNED
jrgm's fix is now checked in. 
actually mark as fixed. 
Status: ASSIGNED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
Ben thanks for checking this in. Just to note though: this was on the trunk
only. Will you be checking in to the branch (i.e., rtm+) after nsbeta3 has
passed?
Re-opening this bug per PDT request because this proposed fix is not yet on the
6.0 branch.
Status: RESOLVED → REOPENED
Priority: P3 → P2
Resolution: FIXED → ---
Whiteboard: [rtm+] → [rtm+] Fix on trunk
require rtm++ for branch. 
Status: REOPENED → ASSIGNED
Note for PDT: This is a one-line correction to basically a typo, it restores
end user functionality that was working in PR2, it is reviewed, and has 
very minimal risk.
PDT marking [rtm++]
Whiteboard: [rtm+] Fix on trunk → [rtm++] Fix on trunk
another one bites the dust
Status: ASSIGNED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
... and another one's gone, and another one's gone, another one bites the dust.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.