6085 - Middle-click on link should load the link in new window

Status: VERIFIED WORKSFORME

(SeaMonkey :: UI Design, defect, P2)

Description

[Chris McAfee]

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

Comment 1

[leger]

Updating QA Contact.

Comment 2

[leger]

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

Comment 3

[Radha on family leave (not reading bugmail)]

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

Comment 4

[don]

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

Comment 5

[Akkana Peck]

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?

Comment 6

[Radha on family leave (not reading bugmail)]

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

Comment 7

[Matthew Tuck [:CodeMachine]]

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

Comment 8

[tor]

Attachment: middle mouse click patch

Comment 9

[tor]

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.  [e-mail]
has a patch ready for #10388 which he will submit tomorrow, after which
apprunner will gain the middle-click feature.

Comment 10

[tor]

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

Comment 11

[Bill Law]

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.

Comment 12

[Mats Palmgren (inactive)]

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

Comment 13

[Matthew Tuck [:CodeMachine]]

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

Comment 14

[Peter Doyle]

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

Comment 15

[Dan Erikson]

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

Comment 16

[Dan Erikson]

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

Comment 17

[Dan Erikson]

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

Comment 18

[Mats Palmgren (inactive)]

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

Comment 19

[Dan Erikson]

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

Comment 20

[Dan Erikson]

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

Comment 21

[leger]

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

Comment 22

[Dan Erikson]

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

Comment 23

[Sitsofe Wheeler]

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

Comment 24

[Richard Zach]

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

Comment 25

[Jerry Baker]

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

Comment 26

[Akkana Peck]

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.

Comment 27

[Kevin Puetz]

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!

Comment 28

[Akkana Peck]

Attachment: XUL/JS patch

Comment 29

[Alec Flett]

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 

Comment 30

[David Härdeman]

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

Comment 31

[Akkana Peck]

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

Comment 32

[Phil Peterson]

PDT-

Comment 33

[Matthew T (active 1999-2002)]

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

Comment 34

[Simon Fraser [no longer active]]

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

Comment 35

[Kevin Puetz]

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.

Comment 36

[leger]

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

Comment 37

[Kevin Puetz]

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.

Comment 38

[Deven Corzine]

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?

Comment 39

[Christian Mattar]

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

Comment 40

[Akkana Peck]

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

Comment 41

[sairuh (rarely reading bugmail)]

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

Comment 42

[Akkana Peck]

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

Comment 43

[Kevin Puetz]

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

Comment 44

[Kevin Puetz]

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

Comment 45

[Kevin Puetz]

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

Comment 46

[Kevin Puetz]

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

Comment 47

[Kevin Puetz]

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

Comment 48

[Asa Dotzler [:asa]]

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

Comment 49

[sairuh (rarely reading bugmail)]

coolio. verif on linux opt comm build 2000.03.27.11.

Comment 50

[Asa Dotzler [:asa]]

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

Comment 51

[David Härdeman]

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?

Comment 52

[Akkana Peck]

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

Comment 53

[David Härdeman]

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

Comment 54

[Asa Dotzler [:asa]]

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

Comment 55

[Ben Ruppel]

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

Comment 56

[Sean Richardson]

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

Comment 57

[Matthew T (active 1999-2002)]

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

Comment 58

[Jason Tibbitts]

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

Comment 59

[sairuh (rarely reading bugmail)]

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.

Comment 60

[Akkana Peck]

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.

Comment 61

[sairuh (rarely reading bugmail)]

cool. verif on linux [opt comm] 2000.05.18.08.

Comment 62

[Dan Rosen]

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.

Comment 63

[Jesse Ruderman]

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

Comment 64

[Chris McAfee]

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.

Comment 65

[Jesse Ruderman]

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?

Comment 66

[sairuh (rarely reading bugmail)]

...and vrfy wfm.

Comment 67

[Ben Ruppel]

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

Comment 68

[Jesse Ruderman]

blake thinks that the new regression is bug 63950.

Comment 69

[Ben Ruppel]

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.

Comment 70

[hennessy]

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

Comment 71

[Akkana Peck]

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?

Comment 72

[Gilles Durys]

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

Comment 73

[Gilles Durys]

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

Comment 74

[Akkana Peck]

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

Comment 75

[Steffen Hehn]

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