317952 - When downloads window is active, bookmarks in folders in bookmarks bar ignore tabbed browsing prefs

Status: RESOLVED INCOMPLETE

(Camino Graveyard :: Tabbed Browsing, defect)

Description

[froodian (Ian Leue)]

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

[Samuel Sidler (old account; do not CC)]

Yeah, I see this. It's kind of random case though. Not many users probably do this...

Comment 2

[Chris Lawson (gone)]

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.

cl

Comment 3

[Chris Lawson (gone)]

Further note: we do the right thing when the frontmost window is another browser window.

cl

Comment 4

[froodian (Ian Leue)]

This also happens if another app is in front.

Comment 5

[froodian (Ian Leue)]

Attachment: Patch

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

[froodian (Ian Leue)]

Comment on attachment 231353 [details] [diff] [review]
Patch

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

[froodian (Ian Leue)]

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

[Chris Lawson (gone)]

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

[Chris Lawson (gone)]

(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

http://lists.apple.com/archives/cocoa-dev/2006/Aug/msg01486.html

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

[Alfonso]

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

[Stuart Morgan]

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.