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

verified dup of 52185 "middle button click on scrollbar when at ftp-site pastes clipboard to URL-field"

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

-> evaughan, for the interim.

... but primarily for why the event.target has become confused.

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

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

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.

I know what's going on and this is the correct fix. Hyatt posted to .xpfe earlier. r=alecf

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.

SR = myself. I've applied this patch in my tree and will check in to the trunk asap.

jrgm's fix is now checked in.

actually mark as 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.

require rtm++ for branch.

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

another one bites the dust

... and another one's gone, and another one's gone, another one bites the dust.