Closed Bug 6085 Opened 21 years ago Closed 20 years ago

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

Categories

(SeaMonkey :: UI Design, defect, P2, major)

x86
Windows 2000

Tracking

(Not tracked)

VERIFIED WORKSFORME

People

(Reporter: mcafee, Assigned: akkzilla)

References

Details

(Keywords: platform-parity, regression)

Attachments

(2 files)

Gtk: middle-mouse click should load URL in new window
Assignee: don → radha
Component: Apprunner → XPApps
Priority: P3 → P2
Target Milestone: M9
Updating QA Contact.
Status: NEW → ASSIGNED
*** Bug 8122 has been marked as a duplicate of this bug. ***
Depends on: 11095
Summary: Gtk: middle-mouse click should load URL in new window → [FEATURE] Gtk: middle-mouse click should load URL in new window
Target Milestone: M9 → M12
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
Summary: [FEATURE] Gtk: middle-mouse click should load URL in new window → [FEATURE] Middle mouse click on link to load URL in new window
*** Bug 11737 has been marked as a duplicate of this bug. ***
Blocks: 10575
QA Contact: beppe → cpratt
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?
Summary: [FEATURE] Middle mouse click on link to load URL in new window → [FEATURE] Middle mouse click on link should load the link in new window
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. ***
Depends on: 10388
Summary: [FEATURE] Middle mouse click on link should load the link in new window → [FEATURE] [patch] Middle mouse click on link should load the link in new window
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.
Depends on: 17468
No longer depends on: 10388
#10388 got marked as a duplicate, changing dependency to bug number #17468.
Summary: [FEATURE] [patch] Middle mouse click on link should load the link in new window → [FEATURE] [patch] [Webshell] Middle mouse click on link should load the link in new window
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.
Target Milestone: M13 → M15
No longer blocks: 10575
*** 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. ***
Summary: [FEATURE] [patch] [Webshell] Middle mouse click on link should load the link in new window → [4.xP][FEATURE][patch][Webshell] Middle-click on link should load the link in new window
*** Bug 24236 has been marked as a duplicate of this bug. ***
Keywords: patch
Summary: [4.xP][FEATURE][patch][Webshell] Middle-click on link should load the link in new window → [4.xP][FEATURE][Webshell] Middle-click on link should load the link in new window
*** 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.
Keywords: 4xp
*** Bug 25643 has been marked as a duplicate of this bug. ***
Summary: [4.xP][FEATURE][Webshell] Middle-click on link should load the link in new window → [FEATURE][Webshell] Middle-click on link should load the link in new window
*** 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.
Assignee: radha → akkana
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
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!
Attached patch XUL/JS patchSplinter Review
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 
Keywords: beta1
QA Contact: cpratt → sairuh
Whiteboard: Fixed, will check in at first opportunity
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-
Whiteboard: Fixed, will check in at first opportunity → [PDT-] Fixed, will check in at first opportunity
*** 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.
Whiteboard: [PDT-] Fixed, will check in at first opportunity → Fixed, will check in at first opportunity
Putting on PDT- radar for beta1.  Will take after the branch.
Whiteboard: Fixed, will check in at first opportunity → [PDT-]Fixed, will check in at first opportunity
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! 
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
*** 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.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
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.
Status: REOPENED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
cool. verif on linux [opt comm] 2000.05.18.08.
Status: RESOLVED → VERIFIED
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.
Severity: normal → major
Status: VERIFIED → REOPENED
Keywords: beta1, patchpp, regression, rtm
OS: other → Windows 2000
Hardware: Other → PC
Resolution: FIXED → ---
Summary: [FEATURE][Webshell] Middle-click on link should load the link in new window → Middle-click on link should load the link in new window
Whiteboard: [PDT-]Fixed, will check in at first opportunity
Target Milestone: M15 → ---
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.
Status: REOPENED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → VERIFIED
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 :)
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.