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
Yeah, I see this. It's kind of random case though. Not many users probably do this...
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
Further note: we do the right thing when the frontmost window is another browser window. cl
This also happens if another app is in front.
Created attachment 231353 [details] [diff] [review] 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 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.
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).
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.
(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.
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?
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.