Gtk: middle-mouse click should load URL in new window

Updating QA Contact.

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

I need notifications on nsILinkHandler for a middle mouse click to be able to do this. Marking this bug dependant on 11095.Adding FEATURE to summary. Moving to M12

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

The summary is misleading ... I assumed the bug was that middle-mouse "pasting" a url into the content area of the browser window should open up that url, which has nothing to do with whether you're over a link or not. Can someone clarify which of these this bug really is?

This bug is for, "If you middle-mouse click on a link, it s'd open that link in a new window.

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

The attached patch will enable the middle-click on link behavior in viewer. Apprunner will do nothing on a middle-click due to bug #10388. jst@citec.fi has a patch ready for #10388 which he will submit tomorrow, after which apprunner will gain the middle-click feature.

#10388 got marked as a duplicate, changing dependency to bug number #17468.

The suggested patch might make this work in Mozilla (and viewer) but I'm not sure it's the right way to do it. I would think the behavior of clicking on links should be controlled by the embedding application, not by code deep in the guts of HTML anchor elements. There's another bug re: clicking on a link while the shift-key is held down. That one's waiting for enhancement to the nsILinkHandler interface (and likely, changes to nsIWebShell and its friends). Of course, there's something to be said for "getting it to work in Mozilla" so perhaps I'm setting my standards too high... I'll add [Webshell] to the summary so this gets looked at during the webshell redesign process.

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

The original msg implies GTK, but the fields imply cross-platform, which is this for?

I would like to see the middle click customizable, instead of hardcoded. Check out bug 18251 for my thoughts.

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

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

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

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

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

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

Setting the keyword all open [4.xp] bugs to 4xp.

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

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

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

If at all possible can this be made XP? It would be a cool feature but I'm on Windoze.

I have changes to navigator.xul in my tree that make this happen. Radha, I hope you don't mind my taking this bug (if you do mind, feel free to take it back). I agree with law that the embedding app should control this, especially since it's so easy to do; that's what we've done with "middle-click goes to contents of url", which has been in navigator.xul for a while. Pete: yes, it should definitely be customizable and it should be available on all platforms. This will probably be a pref, regarding whether you want to use middle button clicks for mouse scrolling vs. for browser url handling.

akkana - patch? could you attach your changes to navigator.xul? I'd really like this to work again (it's so convenient). Thanks! Mmm... this dogfood gets better and better!

nominate for beta since we have a patch in hand - this has been in 4.x since the beginning of time on unix and it's TREMENDOUSLY useful! this should have been a [dogfood] bug

I can verify that this works on a Linux build pulled from CVS 20000303. Two questions though: A) Is the goal still to have it customizable? (like changing a value in edit->preferences, not editing xul/js) B) Is it possible to make the middleclick work elsewhere than the browser area? (like bookmarks in sidebar, or clicking tinderbox in sidebar). Cause it doesn't right now

A) For preffing this feature, see bug 24571 (which I've nominated as beta1, and I hope to get permission to check these in at the same time -- that's how I've primarily been testing them). B) Good point -- the middle click call should be added to the XUL for the other windows as well. Is that important enough to argue for including it in beta1? It would be okay with me if it would be okay with the PDT committee (it would presumably be one line in each of the two XUL files, duplicating the line that's already there in navigator.xul).

PDT-

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

FYI: command-click on Mac should load in a new window too.

Could this be reconsidered for Beta1? It's been in my local tree for some time without any problems, and is really seems quite low-risk and handy. Since this feature has been in 4.x for so long, I think a lot of people are going to miss it if it's not there. With a patch in hand I don't see why it couldn't be.

Putting on PDT- radar for beta1. Will take after the branch.

Well, if that's your decision I guess that's that. This RFE seems to be one of the most often-repeated complaints I read in discussions of mozilla and with a simple, clean patch in hand I don't see why we wouldn't want to fix it. But it's not my call to make.

I must say, I'm rather disappointed at the PDT's refusal to approve this for beta1, especially with a working (and simple) patch in hand. As one of the many users waiting for this simple yet critical feature, I feel this ought to have been a dogfood bug. Right now there's 24 votes on this bug and 14 identified duplicates of this bug. Doesn't this give a hint of just how important this is to many people? Do you really think a Netscape-branded beta without this feature will go over well with those people? It's a simple feature long supported by Netscape 4.x and heavily used by many people; failing to support it in a _beta_ will look rather pathetic, won't it? (How will we convince people how powerful and flexible Mozilla is when something this simple is rejected out of hand?) Please reconsider this decision. At least LOOK at the patch before rejecting it again, wouldn't you? It couldn't get much simpler -- ONE line of XUL is changed and only a few lines of Javascript are changed, and that Javascript is ONLY called by that changed XUL line. How could this possibly make the build less stable? It won't even be executed unless someone clicks the middle button -- and if they do, they're probably expecting this feature to work! Sorry if I sound like I'm ranting here; I appreciate that there are far more important issues for beta1. Still, does it hurt to take a couple minutes to check in this already-working code?

Leger said it will be in AFTER the branch, which was yesterday. So you should see this in the Mozilla-builds quite soon now.

M15 is finally here -- it's checked in!

basic question, but: i take it this was checked into the tip, not the beta1 branch...?

Yes, the tip: this was PDT- and wasn't allowed on the beta branch.

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

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

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

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

whoa, I'm not sure why bugzilla posted that dup message 5 times... I certainly didn't. sorry to all who got spammed :-)

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

coolio. verif on linux opt comm build 2000.03.27.11.

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

Im sorry but I dont have access to any recent mozilla builds right now so I'll just have to ask. Has the feature been enabled in other areas than the browser area (like the bookmark list) as was discussed before?

It hasn't been added anywhere else as far as I know. I'd suggest filing separate bugs on the windows where you'd like to see this enabled, since the windows all have their own event handlers and JS files and are owned by different people. (CC me, though, since I can help the owners of those windows in adding the feature.)

bug #33758 (middle-click in sidebar) and bug #33761 (middle-click in bookmark pulldown) added

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

How about this feature for win9x? I went ahead and filed Bug 34723.

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

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

This seems to be back in Linux build 200051608. A middle click briefly changes the link color but doesn't open a new window. The following appears on the console: chrome://navigator/content/navigator.js line 1086: target has no properties

reopening... if this recent regression is due to another bug, feel free to re-resolve this as Fixed (but lemme know the other bug's # :-). thx! able to repro using opt comm bits on linux, 2000.05.16.08.

The regression was apparently due to a joki change to nsEventListenerManager.cpp. He's fixed it; re-pulling and rebuilding fixes the problem for me, so it should work again in the next build.

cool. verif on linux [opt comm] 2000.05.18.08.

On my latest builds, this works fine on linux but *not* on windows. Strange but true. This could be due to work on IE-like middle mousebutton scrolling (see bug 22775), but that's just a guess... [sigh] Reopening, clearing old status, setting "blah" keywords.

wfm win98se with a scroll-wheel mouse, 2000100620, when I add user_pref("middlemouse.openNewWindow", true); to prefs.js .

Looks like Jesse is right, this pref is on by default for unix, off for everyone else. Marking WFM. Please open another bug to change the non-unix default or to add a UI pref somewhere in the pref panel.

filed bugs: bug 55704 Add gui for middle mouse button prefs bug 55705 enable middlemouse.openNewWindow by default on Windows dan rosen - the prefs work for you on Windows, right?

...and vrfy wfm.

This stopped working on my windows2000 system with microsoft intellimouse about a week ago in the nightlies. Can anyone verify? I think it may be related to having it set to "On" by default now (bug 55705 fixed).

blake thinks that the new regression is bug 63950.

Can anybody confirm that this no longer works on win32? I have tried fresh installs of mozilla in Win2k and Win98, but it seems to no longer works. Is there any progress towards a solution? This was a killer feature for me and it's been more than a month now.

I can verify that Mozilla v0.7 release has broken this. Have still to try a recent nightly. :p

The pref still defaults to true on all platforms, so it should work -- something about handling the event must have broken on windows. Need a windows programmer to try it and see what's up -- anthony, does this work for you on windows?

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

Shouldn't we reopen this bug since this feature is still broken on win32 ?

Bug 63950 covers the windows onclick event handling problem. I suggest you join that bug if you want to lobby for a fix.

I think this is a very important feature and should be fixed soon - i hope so :)