Don't focus new tabs opened by left-click or external URL. Allowing the user the choose to override default behavior. Where this would be helpful: If you're opening multiple items from an RSS in Google Reader, the URLs would be sent to a backgrounded tab instead of switching to a new tab. In the current case the newly created tab is given focus, forcing me to switch back to the Google Reader tab.

Since this should only be a couple of lines of code, restricted to the current SWM handling, I think it's reasonable to support.

I'm opposed to exposing this in the GUI, or having it on by default, since it royally messes up the "normal-click means show me this right now" consistent meaning of normal-click.

I agree with Smokey. All this bug is asking for is support. Let the user find out about the hidden pref on his own.

(In reply to comment #2) > I'm opposed to exposing this in the GUI, or having it on by default Oh, I am as well; I should have been clear that I meant that I was confirming it as a hidden pref.

This is easy enough we may as well just knock it off the list now.

Comment on attachment 276588 [details] [diff] [review] fix The patch works as expected for links that would open in new windows, but I think it may be leaving out the external URL portion of the preference. |reuseExistingBrowserWindow:| is only called when Gecko wants to open a link and not when Camino is to open an external URL. Is it our intention to have this only affect new window links? Mozilla's documented behavior of the preference: Determines behavior of pages normally meant to open in a new window (target="_new" or from an external program), but that have instead been loaded in a new tab. True: Load the new tab in the background, leaving focus on the current tab False (default): Load the new tab in the foreground, taking the focus from the current tab. Note: Setting this preference to True will still bring the browser to the front when opening links from outside the browser.

In general, the requests for background loading have all been about clicking links in the browser, so that's all I was concerned with. The external app part feels like it's been shoe-horned in, since saying that external app links are "diverted" content "meant" to open in a new window makes no sense to me. They are meant to open according to what the user's pref is; unlike a _new link there is no intrinsic assumption.

I believe they shoehorned that in there because Firefox devs intend (and have in the UI, iirc) to merge the external apps and SWM prefs into one pref controlling both, which we don't intend to do (and which seems like a bit of a stretch for most users). I think all we need to care about are links that SWM catches. (We'll want to be sure to fix bug 381356 appropriately, too, since adding this hidden pref will make that language more unclear.)

Have I mentioned I love it when backend pref breakdowns are made based on Firefox UI? Let's not overload the pref just because they did. SWM is what we've had feedback about, and I'm not willing to expand this code beyond the SWM method.

Hear hear that.

Comment on attachment 276588 [details] [diff] [review] fix Alright, I agree, so no complaint here. I mentioned it just to make sure we were leaving that behavior out intentionally, and also because comment #0 made reference to it. r=me.

Comment on attachment 276588 [details] [diff] [review] fix still a bit confused, but i guess it makes sense. just seems like we've got tons of prefs that all do similar things. *shrug* sr=pink

Landed on trunk and MOZILLA_1_8_BRANCH.