linux 2000091108 Clicking middle mouse button click on scrollbar when at an ftp-site pastes clipboard to URL-field, so browser will go wherever - or to netscape search-page if the pasted line doesn't make sense. Expected behaviour: Scrolling should work like when in "browser-mode", mailnews etc. and simply scroll in accordance with where on scrollbar i clicked.

I think what is happening is that the click event for middle mouse bubbles up from the directory.xul and is handled in the event handler attached to the 'appContent' <box> in navigator.xul. browserHandleMiddleClick() does do a check to see if the middle-mouse click happened on a browser scrollbar. However, in the case of directory.xul, there is no explicit <scrollbar> in the DOM content for the tree (not really sure why not, but ...). At any rate, it walks up the DOM-tree and gets treechildren, then tree, then window, decides it's not a scrollbar, so it lets the paste of the URL result in loading of that URL. isScrollbar() could bail on finding a <treechildren>, but that would do the wrong thing if you had loaded some .xul over a HTTP connection (for example). Passing on to akkana, who did some of the work for middle-mouse paste (although I think some of the code came from someone else). However, I'm not really sure what to do about this one (but the defect is minor (i.e., inconsistent, but worst case is that the URL is loaded when not wanted)).

well given how slow treeview at ftp sites can be, this was a bummer when it happened. Going back to treeview takes "forever" if it is a site with many directories/files.

adding keyw.

I'm really not the right person for this: I don't know enough XUL to know how to look for the various types of scrollbars which might be there, and in any case, isScrollbar() should be handling that. lxr says that evaughan wrote isScrollbar(), so he seems like the logical owner, or at least someone who would know who was.

Ooops. Sorry, Akkana. Cloudy memory ... it was evaughan who checked this is for Davor Cubranic and Tomi Leppikangas. (And there's nothing wrong with their patch, just a need to account for the "pure XUL" scenario, where the click happens on the scrollbar of a <tree>).

Adding cubranic@cs.ubc.ca and Tomi.Leppikangas@oulu.fi

->future

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

This also happens when middle-clicking on Web page content area (not on a link or a form field).

In the content area, it's a feature and is very much intentional (and has been present in past Netscape versions as well).

Ehemm.. middle click in content area pasting to URL field is NOT a feature in NC 4.7* on linux, nor have i ever seen it in other *nix versions of Netscape. I do find it extremely annoying, so adding a comment about it. I repeatedly find myself pasting some garbage to URL field because i missed middle-clicking a link i intended to open in a new window. As Moz works right now, hitting "stop" button at that point will more often than not render the page useless, links die etc, so i will have to reload the page i was on in order to click the link again. Very very very very annoying. Never seen anything like it, it's as unexpected each time it happens. In NC 4 i have to place the cursor *IN* the url-field to paste with middle button there. And it will NOT take me away from current URL till i add a linefeed in url bar.

I must add: The reason this happens to me fairly often is because i have a scrollwheel mouse. So sometimes when clicking, the wheel moves slightly, thus sending the click to the wrong location - on page instead of link. And poooff - off i go. Wheel-mice are becoming very common also on *nix systems hnow. So I'm pretty confident this "feature" annoy more than myself. Again: It is NOT a default feature on NC4.* on Linux, nor on IRIX. If it is an option, it must be a "hidden" setting i never knew existed.

You can set, in your prefs.js, user_pref("middlemouse.paste", false); This will however disable all use of middlemouse pasting, so middlemouse in the URL bar will no longer work. (You could file an RFE to extend this functionality to make a new pref (e.g., middlemouse.pasteContentArea) to control specifically where a middlemouse would or would not work. But someone would need to pick up the ball and do this coding (although it's really only a few lines of javascript, offhand estimate).

In NS 4.* (and, I think, NS3 and earlier) on Unix, clicking the middle mouse in the content area goes to the url that's on the clipboard (which has the side effect of putting that url into the urlbar). Honest. This is exactly what Mozilla is doing (not pasting to the urlbar, but going to the url). You can turn it off in mozilla, by setting the middlemouse.paste pref to false.

John Morrison's suggestion of using a different pref for middle mouse go-to-url vs middle mouse paste would be very easy: one line in navigator.xul, plus default values for the pref in a couple of other files. I only set it up this way because I figured people who had trouble with accidentally clicking the middle mouse in one context would feel the same about it in other places as well. But if you disagree and think they should be separated, please file an RFE to me and I can set it up that way for future versions.

Heck.. you're right. I've been beta-testing for too long. Or am too stupid. And.. I don't even use scrollwheel mouse on IRIX. Which again would explain why this hasn't annoyed me there; no risk of anything moving while i click w/btn. 2. But a scenario which could be described as "mousewheel users middle clicks prone to cause disaster", is very real. The phraze "dataloss" springs to mind. I'd much prefer moz to simply ignore middle-clicks in content area. Those clicks should be a "clipboard DMZ". Firing blanks. So jrgm's suggestion would indeed save the day for me.. and my SANITY TOO!! ;)

aaand... it's fixed, with the new user_pref("middlemouse.contentLoadURL", false); Fhe fix is in bug 57317: "Middle button on blank area opens clipboard contents as URL in current window" *** This bug has been marked as a duplicate of 57317 ***