When you open new tab in Firefox new tab is opened in background. When you do the same action in Thunderbird new tab is opened in foreground. In Firefox you can change this behaviour. In Thunderbird you cannot. Thunderbird should have option for opening new tabs in background. Configuration via about:config is acceptable for me.

Also suggested as part of bug 467768, which has the primary focus on providing a default opening-as-tab behavior though.

Confirming.

The patch in bug 467768 includes a mostly-working open in background tab implementation, however there are several bugs still to be ironed out there.

Fixed by bug 467768.

In case anyone was wondering, the pref is currently mail.contextMenuBackgroundTabs. Any reason you didn't make it mail.tabs.loadInBackground to align with browser.tabs.loadInBackground?

(In reply to comment #5) > Any reason you didn't make it mail.tabs.loadInBackground to align with > browser.tabs.loadInBackground? Mainly because Enter/double-click doesn't respect the pref, and always opens the tab in the foreground.

Is there a reason for that then? ;) I imagine there are people wanting to line up all the mails the will deal with at a time in background tabs. Even if it doesn't work atm, having a pref whose name is only about context menu seems like it's crying for migration pain and/or confusion later down the road.

(In reply to comment #7) > Is there a reason for that then? ;) Yeah -- clarkbw said over IRC that Enter/double click should always open things in the foreground (be it tabs or windows), and that middle click should be configurable. ccing Bryan.

Likely people with the message pane hidden would want the normal double click configurable too.

(In reply to comment #9) > Likely people with the message pane hidden would want the normal double click > configurable too. Now that we are actually writing unit tests for things (mozmill tests in the current case), I think it makes sense to try and keep our feature set and therefore our test matrix reasonable in size and defer ultimate extensibility to the domain of extensions.

Right, I want to keep the options simple and create less preferences which hopefully leads to more extensions. We can open a bug if there is no way for an extension to reasonably extend and change this behavior. My plan has been to have a stronger set of default behaviors aimed toward the preferences of the broadest set of users while improving the extension experience both for developers and extension consumers. The developer experience for extensions has dramatically improved with the STEEL extension API and the Gloda message API; not to mention protovis/jquery. The add-on manager is our only client side consumer for extensions and we can do better than that w/ an about:addons page for browsing and installing. (i don't think there's a bug for that yet) The threadpane sanitizer is an excellent example of behavior changes that are best left to add-on development instead of cumbersome preferences UI. https://addons.mozilla.org/en-US/thunderbird/addon/12468 Sorry I'm so off topic, I really need a page that coordinates the different extension efforts underway. Perhaps I will go find space on the wiki...