Last Comment Bug 317952 - When downloads window is active, bookmarks in folders in bookmarks bar ignore tabbed browsing prefs
: When downloads window is active, bookmarks in folders in bookmarks bar ignore...
Status: NEW
Product: Camino Graveyard
Classification: Graveyard
Component: Tabbed Browsing (show other bugs)
: unspecified
: PowerPC Mac OS X
-- minor (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
Depends on: 333765
  Show dependency treegraph
Reported: 2005-11-27 13:56 PST by froodian (Ian Leue)
Modified: 2010-02-02 20:12 PST (History)
4 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---

Patch (1.31 KB, patch)
2006-07-30 19:01 PDT, froodian (Ian Leue)
froodian: review-
Details | Diff | Splinter Review

Description User image froodian (Ian Leue) 2005-11-27 13:56:30 PST
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051127 Camino/1.0b1+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051127 Camino/1.0b1+

When the downloads folder is active, command-clicking on bookmarks conatained in folders in the bookmarks bar always opens the bookmark in a new window, even if the pref is set to open links in new tabs on Cmd-click.  It also ignores the "new windows load  in background" pref, and always loads in the foreground.

Reproducible: Always

Steps to Reproduce:
1. Open the downloads window
2. With the downloads window still in front, cmd-click on a folder in the bookmarks bar
3. Select a bookmark contained in said folder

Actual Results:  
Opens link in new window in foreground

Expected Results:  
Obey pref settings for cmd-clicking links
Comment 1 User image Samuel Sidler (old account; do not CC) 2005-11-27 15:37:43 PST
Yeah, I see this. It's kind of random case though. Not many users probably do this...
Comment 2 User image Chris Lawson (gone) 2005-11-28 05:40:01 PST
I suspect what's going on here is the window controller is (rightly) seeing that it can't open a new tab in the frontmost window, and is therefore opening a new window.

What it *should* be doing is making a new tab in the window in which the click was registered.

Comment 3 User image Chris Lawson (gone) 2005-11-28 05:41:32 PST
Further note: we do the right thing when the frontmost window is another browser window.

Comment 4 User image froodian (Ian Leue) 2006-06-29 05:40:48 PDT
This also happens if another app is in front.
Comment 5 User image froodian (Ian Leue) 2006-07-30 19:01:01 PDT
Created attachment 231353 [details] [diff] [review]

I'm a little scared about this patch, just because it touches |loadBookmark| which I know is kinda fragile, but I think that conceptually it's the right change, and it doesn't seem to break anything...
Comment 6 User image froodian (Ian Leue) 2006-07-30 20:16:01 PDT
Comment on attachment 231353 [details] [diff] [review]

This isn't really the way to do this.  Specifically, we want Cmd-Click on bookmark menu items (from the main bookmarks menu) to open in new windows in these cases - The only reason bookmark bar items shouldn't open in new windows is because they're "attached" to a window.

Codewise, items from the main bookmarks menu and the bookmark folder menus both call |openMenuBookmark| in MainController.  This code is all tied up in bug 333765, so it's gonna have to wait for that.
Comment 7 User image froodian (Ian Leue) 2006-08-22 07:20:54 PDT
This bug sucks.  Basically, the existing patch makes it so that cmd-click on menu bookmarks (from bookmarks bar or bookmarks menu) will always open in tabs in the *frontmost* browser window (assuming the tabs pref is set).

The problem is that we want

a) bookmarks from the bookmarks menu to always open in a new window if a browser window isn't frontmost, and follow the pref if a browser window is.

b) bookmarks from bookmarks bar menus to always follow the pref, opening in a new tab *in the browser window they were invoked from* if it's not frontmost.

It's the "in the browser window they were invoked from unless it's a bookmarks menu item, then in a new browser window" bit that's annoying.  I might realize a nice way to do this suddenly, but until then I'm not really interested in fixing this fringe case (despite the fact that I filed it when I was just a user).
Comment 8 User image Chris Lawson (gone) 2007-02-22 22:19:07 PST
Can you look up the view hierarchy and see if the item has a browser window as one of its parent views? That'd be an easy way to differentiate between bookmarks menu items and bookmarks bar items.
Comment 9 User image Chris Lawson (gone) 2007-10-03 23:05:03 PDT
(In reply to comment #8)
> Can you look up the view hierarchy and see if the item has a browser window as
> one of its parent views?

Gonna reply to my own comment so no one else wastes time trying to chase this down: the answer to the above is "no", according to everything I've been able to find. There is no way to know the view a menu was invoked for once the menu has been displayed. See also

And since both menus are instances of BookmarkMenu, I agree with Ian that this bug totally sucks. I don't see any reasonable way to differentiate the two menus, which I guess makes this a CANTFIX unless anyone has any brilliant ideas.
Comment 10 User image Alfonso 2009-11-06 09:37:59 PST
I have a similar problem in my Mac OS 10.4.11   I cannot drag the URL to save it in my Bookmarks bar.  I am forced to open the pull-down menu and scroll or clic several times until I get to the folder in my bar where I want the bookmark to be. This is cumbersome.  Why, if it didn't happen with Firefox 3.0, is now happening with Firefox 3.5?  Are you going backwards?
Comment 11 User image Stuart Morgan 2009-11-06 12:39:40 PST
This bug is a) for Camino, and b) about something completely different that what you are describing, so you should find/file a different bug.

Note You need to log in before you can comment on or make changes to this bug.