Closed
Bug 6085
Opened 26 years ago
Closed 24 years ago
Middle-click on link should load the link in new window
Categories
(SeaMonkey :: UI Design, defect, P2)
Tracking
(Not tracked)
VERIFIED
WORKSFORME
People
(Reporter: mcafee, Assigned: akkzilla)
References
Details
(Keywords: platform-parity, regression)
Attachments
(2 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
Gtk: middle-mouse click should load URL in new window
Assignee: don → radha
Component: Apprunner → XPApps
Priority: P3 → P2
Target Milestone: M9
Updated•26 years ago
|
Status: NEW → ASSIGNED
Updated•26 years ago
|
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
Comment 3•26 years ago
|
||
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
Updated•25 years ago
|
QA Contact: beppe → cpratt
Assignee | ||
Comment 5•25 years ago
|
||
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?
Updated•25 years ago
|
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
Comment 6•25 years ago
|
||
This bug is for, "If you middle-mouse click on a link, it s'd open that link in
a new window.
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.
Comment 10•25 years ago
|
||
#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
Comment 11•25 years ago
|
||
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•25 years ago
|
||
*** Bug 19202 has been marked as a duplicate of this bug. ***
Comment 13•25 years ago
|
||
The original msg implies GTK, but the fields imply cross-platform, which is this
for?
Comment 14•25 years ago
|
||
I would like to see the middle click customizable, instead of hardcoded. Check
out bug 18251 for my thoughts.
Updated•25 years ago
|
Target Milestone: M13 → M15
Comment 15•25 years ago
|
||
*** Bug 21991 has been marked as a duplicate of this bug. ***
Comment 16•25 years ago
|
||
*** Bug 21500 has been marked as a duplicate of this bug. ***
Comment 17•25 years ago
|
||
*** Bug 21726 has been marked as a duplicate of this bug. ***
Updated•25 years ago
|
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
Comment 18•25 years ago
|
||
*** Bug 24236 has been marked as a duplicate of this bug. ***
Updated•25 years ago
|
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
Comment 19•25 years ago
|
||
*** Bug 25249 has been marked as a duplicate of this bug. ***
Comment 20•25 years ago
|
||
*** Bug 25408 has been marked as a duplicate of this bug. ***
Comment 22•25 years ago
|
||
*** Bug 25643 has been marked as a duplicate of this bug. ***
Updated•25 years ago
|
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
Comment 23•25 years ago
|
||
*** Bug 27671 has been marked as a duplicate of this bug. ***
Comment 24•25 years ago
|
||
*** Bug 28414 has been marked as a duplicate of this bug. ***
Comment 25•25 years ago
|
||
If at all possible can this be made XP? It would be a cool feature but I'm on
Windoze.
Assignee | ||
Comment 26•25 years ago
|
||
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
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Comment 27•25 years ago
|
||
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!
Assignee | ||
Comment 28•25 years ago
|
||
Comment 29•25 years ago
|
||
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
Assignee | ||
Updated•25 years ago
|
Whiteboard: Fixed, will check in at first opportunity
Comment 30•25 years ago
|
||
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
Assignee | ||
Comment 31•25 years ago
|
||
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•25 years ago
|
||
PDT-
Whiteboard: Fixed, will check in at first opportunity → [PDT-] Fixed, will check in at first opportunity
Comment 33•25 years ago
|
||
*** Bug 30360 has been marked as a duplicate of this bug. ***
Comment 34•25 years ago
|
||
FYI: command-click on Mac should load in a new window too.
Comment 35•25 years ago
|
||
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
Comment 36•25 years ago
|
||
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
Comment 37•25 years ago
|
||
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•25 years ago
|
||
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•25 years ago
|
||
Leger said it will be in AFTER the branch, which was yesterday. So you should
see this in the Mozilla-builds quite soon now.
Assignee | ||
Comment 40•25 years ago
|
||
M15 is finally here -- it's checked in!
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Comment 41•25 years ago
|
||
basic question, but: i take it this was checked into the tip, not the beta1
branch...?
Assignee | ||
Comment 42•25 years ago
|
||
Yes, the tip: this was PDT- and wasn't allowed on the beta branch.
Comment 43•25 years ago
|
||
*** Bug 32804 has been marked as a duplicate of this bug. ***
Comment 44•25 years ago
|
||
*** Bug 32804 has been marked as a duplicate of this bug. ***
Comment 45•25 years ago
|
||
*** Bug 32804 has been marked as a duplicate of this bug. ***
Comment 46•25 years ago
|
||
*** Bug 32804 has been marked as a duplicate of this bug. ***
Comment 47•25 years ago
|
||
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•25 years ago
|
||
*** Bug 32614 has been marked as a duplicate of this bug. ***
Comment 49•25 years ago
|
||
coolio. verif on linux opt comm build 2000.03.27.11.
Status: RESOLVED → VERIFIED
Comment 50•25 years ago
|
||
*** Bug 33716 has been marked as a duplicate of this bug. ***
Comment 51•25 years ago
|
||
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?
Assignee | ||
Comment 52•25 years ago
|
||
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•25 years ago
|
||
bug #33758 (middle-click in sidebar) and bug #33761 (middle-click in bookmark
pulldown) added
Comment 54•25 years ago
|
||
*** Bug 34699 has been marked as a duplicate of this bug. ***
Comment 55•25 years ago
|
||
How about this feature for win9x? I went ahead and filed Bug 34723.
Comment 56•25 years ago
|
||
*** Bug 34972 has been marked as a duplicate of this bug. ***
Comment 57•25 years ago
|
||
*** Bug 22479 has been marked as a duplicate of this bug. ***
Comment 58•25 years ago
|
||
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•25 years ago
|
||
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 → ---
Assignee | ||
Comment 60•25 years ago
|
||
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: 25 years ago → 25 years ago
Resolution: --- → FIXED
Comment 62•24 years ago
|
||
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
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 → ---
Comment 63•24 years ago
|
||
wfm win98se with a scroll-wheel mouse, 2000100620, when I add
user_pref("middlemouse.openNewWindow", true); to prefs.js .
Reporter | ||
Comment 64•24 years ago
|
||
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: 25 years ago → 24 years ago
Resolution: --- → WORKSFORME
Comment 65•24 years ago
|
||
Comment 67•24 years ago
|
||
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•24 years ago
|
||
blake thinks that the new regression is bug 63950.
Comment 69•24 years ago
|
||
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•24 years ago
|
||
I can verify that Mozilla v0.7 release has broken this. Have still to try a
recent nightly. :p
Assignee | ||
Comment 71•24 years ago
|
||
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•24 years ago
|
||
*** Bug 66471 has been marked as a duplicate of this bug. ***
Comment 73•24 years ago
|
||
Shouldn't we reopen this bug since this feature is still broken on win32 ?
Assignee | ||
Comment 74•24 years ago
|
||
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•24 years ago
|
||
I think this is a very important feature and should be fixed soon - i hope so :)
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•