If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Add option for opening message in tab in background

RESOLVED FIXED in Thunderbird 3.0b3

Status

Thunderbird
Toolbars and Tabs
--
enhancement
RESOLVED FIXED
9 years ago
8 years ago

People

(Reporter: JasnaPaka, Assigned: sid0)

Tracking

(Blocks: 1 bug)

unspecified
Thunderbird 3.0b3
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fixed by bug 467768])

(Reporter)

Description

9 years ago
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.

Comment 1

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

Comment 2

9 years ago
Confirming.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: 392328
(Assignee)

Comment 3

8 years ago
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.
Assignee: nobody → sid.bugzilla
Status: NEW → ASSIGNED
Depends on: 467768
(Assignee)

Comment 4

8 years ago
Fixed by bug 467768.
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
(Assignee)

Updated

8 years ago
Target Milestone: --- → Thunderbird 3.0b3

Comment 5

8 years ago
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?
Whiteboard: [fixed by bug 467768]
(Assignee)

Comment 6

8 years ago
(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.

Comment 7

8 years ago
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.
(Assignee)

Comment 8

8 years ago
(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.

Comment 9

8 years ago
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...
You need to log in before you can comment on or make changes to this bug.