72361 - ctrl+click/middle click a bookmark should open it in new window/new tab

Status: VERIFIED FIXED

(SeaMonkey :: Bookmarks & History, defect, P5)

Description

[Jesse Ruderman]

Steps to reproduce:
1. Pull down the bookmarks menu.
2. Ctrl+click on a bookmark.

Result: bookmark opens in same window
Expected result: bookmark opens in a new window

cf bug 33761, "Middle click to open in new window should work in bookmark 
pulldown menu".

Comment 1

[Blake Ross]

Matthew, is this right, or is this carrying it too far?  I guess it's good to 
be consistent, but I think the odds of any user modified-clicking on a menuitem 
are one in a million.  It's a pretty foreign idea.

Comment 2

[Matthew T (active 1999-2002)]

Coincidentally, I just suggested to a couple of GNOME hackers that instead of 
having a `- - - - -' line at the top of each GTK menu and submenu, to allow 
tearing off the menu into its own window, they should use Control+dragging of 
the menu item instead.

The items in menus are not links, just as the Back and Forward buttons are not 
links. They shouldn't look like links, and they shouldn't behave like links. I 
don't think this should be implemented.

Comment 3

[Ben Goodger (use ben at mozilla dot org for email)]

Paul Chen is now taking Bookmarks bugs. For your convenience, you can filter 
email notifications caused by this by searching for 'ilikegoats'.

Comment 4

[Paul Chen]

Mass move Ben's bugs dumped on me marked future with p5 to get off my untriaged
radar. You can filter out this email by looking for "ironstomachaussie"

Comment 5

[Peter Trudelle]

mass reassign of pchen bookmark bugs to ben

Comment 6

[John Levon]

see bug 116531 too

Comment 7

[Chris Lyon]

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

Comment 8

[Bamm Gabriana]

No, Bug 137648 is not a dupe. Here are the differences:

1) This one wants Ctrl+Click to open bookmarks in a new Window
   while Bug 137648 want to open it in a new tab, if properly
   configured in Tabbed Browsing preferences.

2) This one only talks about bookmark menus. Bug 137648 applies
   to bookmark menus, the Personal Toolbar and the Manage Bookmarks
   dialog box.

3) This one wants it to be the default for Ctrl+Click. Bug 137648
   wants it to be set in the Tabbed Browsing prefs.

Please reopen the other bug.

Comment 9

[Pierre Chanial]

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

Comment 10

[Matthias Versen [:Matti]]

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

Comment 11

[Rob Hagopian]

There seems to be a big circle of these bugs (eg. this -> bug 137648, bug 50504,
bug 93033 -> this), with this the only open one I could find. As we're in RC3
does this mean that in 1.0 there will be no way to click on a bookmark in the
sidebar and have it load in a new _tab_ (see last behavior)?

Currently the behaviors (latest build under linux) are:
- middle click opens in the active tab
- single and double click open in the active tab
- ctrl-click adds the clicked bookmark to the selection in the sidebar, and
opens the clicked bookmark in the active tab
- shift-click expands the selection (as with text) to include the clicked
bookmark, and opens the clicked bookmark in the active tab
- alt-click moves the window (a feature of my window manager)
* right click provides a menu option for opening the bookmark in a new _window_,
which it does despite any tabbing prefs (ie. it will not open in a new _tab_,
belying a coment in one bug that 'new window' and 'new tab' were interchangible)

Being a big tab and sidebar bookmark user I'd love to see another menu item with
the option added for 'new tab' which would strike me as a minor change (would a
patch be accepted?)...

Comment 12

[Rob Hagopian]

Ah... found more info in bug 112639

I'm still surprised at the right-click menu option (new window, but not new
tab), but any changes appear to be slated for 1.0.1...

Comment 13

[Graham Layman]

I am running win2k and only recently started using mozilla. The very first day I
tried opening bookmarks in a new tab and was dissapointed to see that it wasn't
implemented. This is a feature that I for one would really like to have.

Comment 14

[Christopher Aillon (sabbatical, not receiving bugmail)]

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

Comment 15

[brian]

Please change this to

severity: enhancement
OS: all

Comment 16

[Boris Zbarsky [:bzbarsky]]

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

Comment 17

[jlarsen]

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

Comment 18

[Stefan Borggraefe]

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

Comment 19

[Jonadab the Unsightly One (Nathan Eady)]

> I think the odds of any user modified-clicking on a 
> menuitem are one in a million.

The odds of any user modified-clicking a menuitem
*without knowing about the feature* are pretty low.

But, if the user _does_ do that, what will he expect
it to do?  Assume for the moment that he already
knows, from reading stuff in the prefs panel, that
_links_ can be ctrl-clicked or middle-clicked to open
them in new tabs.  What will he think/hope will happen
if he ctrl-clicks or middle-clicks a bookmark, in the 
bookmarks manager or bookmarks menu or in the sidebar
or on the personal/links toolbar?

Personally, I would find this really useful.  Indeed, 
sometimes I've wished I could right-click the back
button and choose "new tab". 

Comment 20

[nmichael]

I couldn't agree with you more.  In fact even though I know it does not work now
I sometimes catch myself doing exactly that since I am so used to it by
middle-clicking on links on web pages.  And we are not just talking about links
in menus.  It is most useful when the user lists his bookmarks in the sidebar. 
For the brouser to give a different behavior between those links and the links
inside a web page is completely counter-intuitive.

Comment 21

[Martin Macok]

Another experience: My girlfriend is ''just a user''. Once I told her about tabs and about middle-clicking a link in a page she was happy and she liked it. Several minutes later I saw her middle-clicking bookmarks item in the sidebar and telling "it doesn't work now!" ... I'm a bit more experienced user and I also sometimes middle-click (or ctrl-click) on it ''accidentally''.  From the other point of view: Is something bad on this feature if it is implemented?

Comment 22

[Darren Salt]

Middle- or ctrl-clicking on items in the bookmarks menu or bookmarks toolbar,
while useful, would leave other inconsistencies...

I suggest that anything which, when clicked on, will cause a page fetch (from a
server or from browser history), which doesn't already support middle- and
ctrl-clicking for the purpose of opening the page in a new window or tab should
do so.

In addition to the bookmarks, my list includes, but is not limited to, the
following:

* 'Back' and 'Forward', and their menus
* 'Reload'
* 'Home'
* Form submit buttons

In addition (little extra cost?), middle/ctrl-clicking on a bookmarks folder
would cause the URLs to be displayed, rather than the associated names; though
quite how this would be applied to the menu bar bookmarks menu, I'm not sure 
:-)

Comment 23

[Jonadab the Unsightly One (Nathan Eady)]

Form submit is a separate issue (probably, bug 17754).

If someone finds/files another bug for the toolbar
buttons, please add the bug number as a comment here,
but it really should be a separate bug too.  There 
are already numerous places bookmarks appear, so this
bug is sufficiently broad without adding other buttons.

(I do agree that they should get done, but this bug
has enough to do.)

Comment 24

[Martin Macok]

Bug 59132 - Modifier- and middle-click on PT items should behave like links
(personal toolbar)

Comment 25

[HJ]

"The items in menus are not links"

So what are they, goats?

Comment 26

[Christian :Biesinger (don't email me, ping me on IRC)]

this requires bug 126189 to be fixed

Comment 27

[Daniel Wang]

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

Comment 28

[Michael Lefevre]

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

Comment 29

[franCk]

I was about to fill a RFE... but here it is.
As it seems there is debate over the usefulness of this feature, I will try to
add my 2 cents, and sorry for the spam, I know I should not do that, it is not a
forum...

I believe it is not only a problem of consistency, but it is simply useful! I've
been very often trying to use it for the menu under the back arrow. 
Actually when I'm browsing I don't always know where I'm going and when I reach
a page with many interesting links I don't always think to open it in a new tab,
thus I browse a few more page and then I want to come back to this earlier page,
thus I open the menu under the back arrow - and would ideally open it in a new
tab to avoid loosing the content of the page I reached. But I can not.

The next use I have for it is for bookmark, where you can object that I can drag
and drop the link on the tab bar to get that effect (note that this doesn't work
with the back arrow drop down list). But when you're used to it, Ctrl click is
quicker, moreover I hide the Tab bar when I have one link only (to save screen
space) thus can not do that for the first bookmark - and don't tell me for the
first bookmark type ctrl T then drag and drop - frankly, isn't Ctrl+click
simpler and more consistent because it will work for the first and all other
bookmarks I want to open in a new tab?

I know, there are button, drop-down menu (under the back arrow or the URL bar
for example) and link in page and 'they are not the same'... in the developper eyes!
For a user, you click on it and it brings you in a new location thus it must be
some sort of link, no?!
Thus why does those links not support the same modifier (Ctrl)? Actually it is
funny to see that the view of MPT on this issue has changed dramatically, from
his comment #2 to a recent BLog (http://mpt.phrasewise.com/2002/09/08#a343) of
his where he claims... just the opposite!
But apparently, many other Mozilla developper responded to the 'new' view of MPT
to claim that it is stupid and that only 0.02% of the population will use it.
I'm glad to see I'm such a chosen person... but something tells me I'm not that
exceptional!

OK I could accept that it is technically difficult to implement (as comment #26
states, although I don't believe it could really bloat the already 10Mo big
software :-) - but please don't tell me 'bookmark', 'button', 'item in
drop-down' are not links, I trully believe, as the Joe user I am, that they are
(as the guy from comment #25 put it a bit too straightly maybe :-).

Thank you and sorry for the lack of technical content, I just wanted to add my
opinion because I felt the debate over this feature in the Blog I link to (and
the related Blogs of other Mozillian) started to be personal grief, and I would
not that personal matter interfer with making Mozilla ever better :-)
So guys, think back calmly to this feature and tell me if it is a good thing or
not... and, if it can help in getting it done, remember it is not MPT's idea (cf
comment #2:-) (sorry MPT for the pun, I hope you have a good sense of humor :-)

Use the Force Luke :-)

Comment 30

[Chris Lyon]

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

Comment 31

[Chris Lyon]

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

Comment 32

[mozilla]

I'd still like to see this included in Mozilla, but this functionality is now
being provided in the Tabbrowser Extensions available at

http://www.cc-net.or.jp/~piro/xul/_tabextensions.en.html

Comment 33

[Olav Vitters]

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

Comment 34

[Rainer Bielefeld]

This wish is discussed in bug 16477, bug 114314, bug 116531, bug 117449 bug 72361

I think work on the bug should be concentrated in bug 117449, other bugs should
be colosed with DUP.

Comment 35

[Matthias Versen [:Matti]]

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

Comment 36

[Calvin Spealman]

I've found this to be the case on XP as well.  I expect it is also present on
all OSes.

Comment 37

[Olivier Cahagne]

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

Comment 38

[Robert Hinn]

How about making the behaviour of left-, middle- and right-clicking on bookmarks
customizable? I mean, adding combo-boxes to the property sheets, where you can
select from "new window", "new tab", "same tab/window" for left-, middle- and
right-clicks on bookmarks.
Maybe it would make more sense to do it the other way round, i.e. choose from
"left-click", "middle-click", "right-click", "ctrl-left-click", etc. for
bookmark actions "open in new window", "open in new tab" and "open in same
window/tab"...
I would definitely like the option to handle bookmarks and tab-list-bookmarks
differently. When I click a tab-list-bookmark, the current tabs clutter up quite
quickly, so I would rather have tab-list-bookmarks open in a new window...

Comment 39

[karlo walz]

i want to make clear
that the useability of a programm
results in a clear
and consitant use
of functionality.
Mozilla is great in using tabs.

Therefore it is useful to have a consistant modification
key to open in a seperate tab!

contr+click on a bookmark should 
open in either a new window or tab
(which should be possible to set up, by the user in options)

This should work in
 - sidebar -> new tab
 - link in the windows -> new tab
 - bookmarks - new tab

this is a idea how things should work and not a bug.
I for myself do not use a third button mouse
though it is not a great idea to implement it like this.
It is simply a modification of opening links

Greetings Karlo

Comment 40

[Thomas Winzig]

I think the point of this bug is pretty simple. People like the way tabs work,
however they get them to appear (middle-click on the mouse, ctrl-click, etc).
They want to extend this from just working on links to working on other ways of
opening new pages:

- Clicking on bookmarks via the bookmarks menus
- Clicking on bookmarks via the personal toolbar
- Clicking on the 'Home' button
- Clicking on the 'active connection' animated 'M' icon

I believe it would also be intuitive to continue this into any other area that
causes a webpage to be loaded, such as:

- Clicking on submit buttons in web forms
- Clicking on the prev/next arrows
- Clicking on the refresh button

Comment 41

[Alex Hosking]

I noticed this to and almost filed a bug, when I click a link on my personal
toolbar I do not get a new tab, this was not the behaviour I was expecting at
all so it must be a bug.

Comment 42

[Matthias Versen [:Matti]]

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

Comment 43

[Alfonso Martinez]

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

Comment 44

[Andrés G. Aragoneses]

Why not change "PC" and "OS" to "All"?

Comment 45

[Wladimir Palant]

Attachment: Proposed patch

Adds function getTargetFromEvent() to determine the bookmark target according
to the relevant settings (browser.tabs.opentabfor.middleclick,
middlemouse.openNewWindow, browser.tabs.loadInBackground - consistent with the
link behavior). Makes bookmark menus, personal toolbar, bookmark management
window and bookmarks panel use this function. Adds middle-click support for the
personal toolbar (_not_ for the menus - I'm not sure this should be
implemented).

Ctrl-Click on a menu works, Ctrl-Enter doesn't (opens in the current window).
This is a bug of the command event, it only sets ctrlKey for clicks.

The behavior of the Home button in the personal toolbar is inconsistent now - I
will file a separate bug on this.

I'm not sure whether loadBookmarkMiddleClick() is still needed - it cancels DND
but in my tests the click event isn't fired anyway when the user is dragging
something.

Comment 46

[[e-mail]]

Comment on attachment 144949 [details] [diff] [review]
Proposed patch

Just a quick skim through...

>+    if (extendedBehavior) {
...
>+    }
>+
>+    return "current";
Wouldn't it be easier to say if (!extendedBehaviour) return "current"; ?
(possibly even putting that inside the switch)

>     case "current":
>       browser.loadURI(url);
>       w._content.focus();
>       break;
>     case "tab":
>+    case "tab_background":
>       var tab = browser.addTab(url);
>-      browser.selectedTab = tab;
>-      browser.focus();
>+      if (aTargetBrowser != "tab_background") {
>+        browser.selectedTab = tab;
>+        browser.focus();
Might as well fix this as per the "current" case...

>+            onclick="BookmarksToolbar.loadBookmarkMiddleClick(event, this.database)"
No, I don't see the point of this either, try asking pch.

Comment 47

[Stefan Borggraefe]

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

Comment 48

[R.K.Aa.]

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

Comment 49

[Wladimir Palant]

Attachment: Patch v2

Added Neil's corrections. Renamed BookmarksCommmands.getTargetFromEvent() to
BookmarksUtils.getBrowserTargetFromEvent() to match the naming of the same
function in Firefox. I made BookmarksUtils.shouldLoadTabInBackground() a
separate function so I can fix the behavior of the Open in New Tab context menu
later (currently it never opens the tab in background, will be a separate bug).
And I removed BookmarksToolbar.loadBookmarkMiddleClick() - it is only necessary
for middle clicks on menu items but we don't handle them.

Comment 50

[[e-mail]]

Comment on attachment 147136 [details] [diff] [review]
Patch v2

Couldn't get this to apply presumably because of bitrot :-/

>     case "tab":
>+    case "tab_background":
>       var tab = browser.addTab(url);
>-      browser.selectedTab = tab;
>-      browser.focus();
>+      if (aTargetBrowser != "tab_background")
>+        browser.selectedTab = tab;
>       break;
So the "tab_background" case just calls addTab? Hardly seems worthwhile trying
to share the code, at least in this case...

>+    if (PREF && PREF.getBoolPref("browser.tabs.opentabfor.middleclick")) {
>+      return this.shouldLoadTabInBackground(aEvent) ? "tab_background" : "tab";
>+    }
I don't think style here is to have {}s for one line.

>   loadBookmarkBrowser: function (aEvent, aTarget, aDS)
>   {
>+    var target = BookmarksUtils.getBrowserTargetFromEvent(aEvent);
>+    if (!target)
>+      return;
>+
>     var rSource   = RDF.GetResource(aTarget.id);
Could change this to aEvent.target.id and save yourself (and loadBookmark) a
parameter.

>       <method name="openItemKey">
>+        <parameter name="aEvent"/>
>         <body><![CDATA[
>           if (this._selection.length != 1) {
>             return;
>           }
I wonder what the reasoning behind this was... I assume this would work from
the context menu, so why not on Enter?

>-          if (!this._selection.isContainer[0])
>-            BookmarksCommand.openBookmark(this._selection, "current", this.db)
>+          if (!this._selection.isContainer[0]) {
>+            var target = BookmarksUtils.getBrowserTargetFromEvent(aEvent);
>+            if (target)
>+              BookmarksCommand.openBookmark(this._selection, target, this.db)
>+          }
Even if you don't do anything about the length code above it looks as if this
doesn't open groupmarks, it would be neat if it could.

>+            onclick="if (event.button==1) BookmarksUtils.loadBookmarkBrowser(event, event.target, this.database)"
Spaces around == (this was the only incorrect case that I spotted).

Comment 51

[R.K.Aa.]

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

Comment 52

[Wladimir Palant]

(In reply to comment #50)
> So the "tab_background" case just calls addTab? Hardly seems worthwhile trying
> to share the code, at least in this case...

Yes but we have to stay consistent I think - opening a bookmark is _always_ done
by openBookmark() regardless the target window/tab.

As to the other suggestions - I agree (a major cleanup of the bookmarks code
would be neat too, just not in this bug :) but I won't have a possibility to do
something with Mozilla for probably a couple of months. So if somebody is
willing to finish this patch in the meanwhile - feel free to do so.

Comment 53

[Wladimir Palant]

Attachment: Updated patch

I've updated the patch and eliminated bitrot.

> I wonder what the reasoning behind this was... I assume this would work from
> the context menu, so why not on Enter?

No, I tried to remove the check and found out that opening a multiple selection
has quite a few issues. I want to fix them but it should be a separate bug.
Right now a middle-click on a folder works the same way it does on a group
bookmark - I think it is the right thing to do, we just have to make it
consistent for group bookmarks, folders and multiple selections.

> Even if you don't do anything about the length code above it looks as if this

> doesn't open groupmarks, it would be neat if it could.

No, Enter shouldn't do anything on containers in a tree.

As to the rest - agreed and fixed.

Comment 54

[[e-mail]]

Comment on attachment 153658 [details] [diff] [review]
Updated patch

>     case "tab":
>       var tab = browser.addTab(url);
>       browser.selectedTab = tab;
>-      browser.focus();
>+      break;
>+    case "tab_background":
>+      var tab = browser.addTab(url);
>       break;
Forgot to mention: "var tab =" unnecessary (JS strict warning).

Comment 55

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 153658 [details] [diff] [review]
Updated patch

With the JS strict fix that Neil noticed, sr=dmose.

Comment 56

[Wladimir Palant]

Attachment: Patch to be checked in

Removed the unnecessary "var tab".

Comment 57

[Wladimir Palant]

Comment on attachment 153754 [details] [diff] [review]
Patch to be checked in

Carrying over the review flags.

Comment 58

[Wladimir Palant]

Fixed in build 2004072008.

Comment 59

[OstGote!]

(In reply to comment #49)
> And I removed BookmarksToolbar.loadBookmarkMiddleClick() - it is only necessary
> for middle clicks on menu items but we don't handle them.

I hope I understand it: Although the summary says something different, middle
click does not open a bookmark from the bookmarks folder (pulldown menu) on the
personal toolbar or the bookmarks menu. Here works now only Strg+Click for new
tabs/windows. For middle click for the pulldown menus see Bug 33761. So this bug
is as comment 0 states only for Ctrl-Click. Right?

Comment 60

[Wladimir Palant]

Not quite. This bug is also about middle-clicks - on personal toolbar items or
tree items in the bookmarks sidebar, just not on menus (including pulldown menus
for bookmark folders in the PT). The latter is a WONTFIX IMHO.

Comment 61

[Worcester12345]

Not sure if this is a regression or not, but try to middle click or control click on "Other top headlines" at http://www.wtkk.com/ and nothing happens.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060323 Firefox/1.5.0.2 ID:2006032306

Comment 62

[Wladimir Palant]

(In reply to comment #61)
This is a SeaMonkey bug, not Firefox. And this is about bookmarks, not links. And what you are talking about isn't even a bug - "Other top headlines" on this web site simply isn't a link, it is a SPAN element made behave similarly to a link (obviously not similar enough to handle middle-clicks).

Comment 63

[Jesse Ruderman]

Comment 61 sounds like bug 55696.