It seems that there are many cases where tabs are opened in the foreground vs. the background differently. There's very flimsy rationale for this in a few cases but it often breaks down. There is no way to open a link in the foreground using the mouse - unless you flip a default pref. It seems to me that the "select new tabs opened from links" should be a global default toggle, with a modifier key to override in specific instances for deterministic selection. This would be documented in the Tabbed Browsing preferences panel. The default for most users would be to open tabs in the foreground, with a modifier key to override into the background for specific use cases. Switching the pref would invert this.

Marking blocking for investigation.

(In reply to comment #0) > There is no way to open a link in the > foreground using the mouse - unless you flip a default pref. There is Shift+Ctrl+Click.

Oh, unless you meant "with a mouse only". But your other comments made it seem like you didn't - it seems like you're proposing just flipping the pref to "foreground by default".

Will look at this, though I'm not sure breaking existing behaviour is worth it right now.

Wouldn't it be easier to simply decouple the multiple behaviours influenced by the pref 'browser.tabs.loadInBackground' into multiple prefs, each associated with only one behaviour? Off the top of my head, I can think of several things affected by this pref: - tab focus of external links - tab focus of clicked links - tab focus of window.open() calls So far the purpose of this bug is to improve the behaviour surrounding the second function of the pref. By introducing new prefs for the various behaviours influenced by the current pref, it becomes trivial to do what comment #0 suggests.

external and diverted window.open calls honour loadDivertedInBackground, actually. So you're arguing that we should have a separate pref for each action, and then set them all the same? That's really unclear, other than defaulting to something and allowing ultimate flexibility...

(In reply to comment #6) > external and diverted window.open calls honour loadDivertedInBackground, > actually. Indeed they do, and that's a good thing IMO. > > So you're arguing that we should have a separate pref for each action, and then > set them all the same? That's really unclear, other than defaulting to > something and allowing ultimate flexibility... > Not really. I simply think that using the same pref for multiple behaviours is a bad idea. Ideally, there would be at least one pref for the behaviour of links spawned by webpage content (the current one), one pref for the behaviour of links from outside the program (which there is now) and one pref for the behaviour of links spawned by the UI (i.e. the Places infrastructure, the throbber, the EM, the Help Browser, and so on).

So, we support Shift globally as a modifier for inverting default foreground/background actions. We have for a really long time too! I don't think we want to change the default for middle-clicking links, at this stage, without significant data indicating that its the right thing. Asserting boldly, users who consciously open links in new tabs are more likely to be queuing more pages for reading, instead of doing a serial operation. (i.e. I am here, I want to go there, then come back to here.) With bfcache, the penalty for navigating forward then back is no higher than opening a new tab and closing it again to resume reading. Its probably lower in some cases (mice with back buttons, f.e.). All other cases for new tabs are currently opening in the foreground, and that seems to be correct given the likely task in each (which I can enumerate if its not clear what those cases are).

There are currently really only two types of "Open in Tab" actions: 1) "Execute this action which normally takes focus, except do it in a new tab" This covers the following open in new tab actions ... - DDE - window.open() diversions - UI actions like opening bookmarks 2) "Load this link in a new tab" This covers the following open in new tab actions ... - context menu "Open in New Tab" on a link in content - middle click on a link in content Type 1 should be opened with focus by default, and that behaviour shouldn't be changable by any sort of user option. There is no expectation for DDE, window.open() or bookmark links to open in background, nor IMO should there be. A single about:config pref should be available for tweakers to modify this behaviour. Type 2 should be opened without focus by default (for legacy reasons and) to support the "queue this for later reading) behaviour. A user option should be available to switch this, and a modifier key should exist to invert the specified user preference.

(In reply to comment #9) > Type 1 should be opened with focus by default, and that behaviour shouldn't be > changable by any sort of user option. There is no expectation for DDE, > window.open() or bookmark links to open in background, nor IMO should there be. > A single about:config pref should be available for tweakers to modify this > behaviour. Agreed. This would allow the tab extensions to offer UI for people (like my relatives) who like to keep things from stealing focus from their current webpage. > > Type 2 should be opened without focus by default (for legacy reasons and) to > support the "queue this for later reading) behaviour. A user option should be > available to switch this, and a modifier key should exist to invert the > specified user preference. > Again, I agree.

So, going to mark this one WONTFIX, based on the discussion here. We actually have two prefs (one for diverted, one for bookmarks) covering beltzner's second case, but that's historical, and merging them isn't worth the effort at this point.