Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20081211 Minefield/3.2a1pre ID:20081211042349 If a user wants to open tabs from a link into the background (e.g. middleclick on the link) he has to disable "[ ] When I open a link in a new tab, switch to it immediately" (Options->Tabs , the last option. If he middleclicks on a bookmark, by default, the bookmark opens in a new active tab. To get open from bookmarks behave like open from links he has to go to about:config and manually set browser.tabs.loadBookmarksInBackground TRUE This looks like inconsistent behaviour to me. browser.tabs.loadInBackground and browser.tabs.loadBookmarksInBackground should have the same value, so basically one can be removed.
Agree with this, shortcut keys were not mentioned but this would change would make them consistent for bookmarks/history and for links. Firefox 2 and above Tools>Options>Tabs "When I open a link in a new tab, switch to it immediately" relating to browser.tabs.loadInBackground Firefox 1.0.x had an option for "Select New Tabs from Bookmarks or History" relating to loadBookmarksInBackground Any change here should be reflected in http://kb.mozillazine.org/About:config_entries which I had just modified because the fact that links could be modified with the user interface while bookmarks & history could not be, but that the settings would need to be the same for user sanity. The shortcut keys are reversed for Ctrl+click and Ctrl+Shift+click depending on "When I open a link in a new tab, switch to it immediately", so it doesn't make sense to have separate settings when both configurations need to be set to the same value for the shortcut keys to work consistently.
blocking2.0: --- → ?
I respectfully disagree with both Peter and David. I believe that the capability of distinguishing tab behavior (with or without focus) between page links and bookmarks is highly convenient. This is possible in Firefox 3+, but not SeaMonkey 2, due to the presence of both loadInBackground about:config entries browser.tabs.loadBookmarksInBackground browser.tabs.loadDivertedInBackground With both preferences set to False (the default behavior), tabs load as I want them to load. For example, 1) With a list of links generated by an internet search, I can middle-click the first 5 (or 10, or whatever) links, and have them all load in the background as I am perusing the first link. Loading 10 tabs with focus from 10 clicks is almost not worth doing. 2) When I middle or right-click a bookmark on my Personal Toolbar, I can have the link open in a new tab (or window) with the new page having the focus. When opening a single page, this would normally be the desired behavior. And so, having these two preferences allows for the opening of a new tab, with or without focus, independently for both page links and bookmarks. IIRC, this was the default behavior for Netscape 7.2 and Mozilla 1.8, at least WRT the context menu. This is _not_ possible with SeaMonkey 2, as browser.tabs.loadBookmarksInBackground is not implemented. The only option at this time for implementing different behaviors for page links and bookmarks is to add an entry to the context menu (load in new tab with focus) with an Addon (many are not available for SeaMonkey) or by editing XUL/XML. As I said, tabs open for me as I want them in Firefox 3+, but not SeaMonkey 2. On the other hand, there may be those who wish to middle-click several bookmarks and have them load in the background. With browser.tabs.loadBookmarksInBackground set to True, the behavior for page links and bookmarks becomes the same. This is possible in FF 3+, but not SM 2. Even so, it may be preferable to have even more control over tabs being opened with left, middle or right clicks for page links and bookmarks. IOW, keep both preferences (FF and SM), and/or add the options to the context menu to open links or bookmarks in new tabs/windows with or without focus. Just my 0.02. Again, respectfully.
No longer depends on: 987117
Duplicate of this bug: 987117
You need to log in before you can comment on or make changes to this bug.