Add a sidebar container for extensions to hook into



11 years ago
9 months ago


(Reporter: Fallen, Unassigned)



Dependency tree / graph
Bug Flags:
wanted-thunderbird +
blocking-thunderbird3 -

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [no l10n impact], )

Some extensions will want to add a sidebar to Thunderbird. One of them is Lightning, which needs the today pane on the right side.

This bug should be used to implement the container in Thunderbird. Open questions that come to mind:

* Where should the container be placed?
  - Left, Right, Both?
  - Lightning needs the today pane on the right side

* Should the sidebar be under the tabstrip or next to it? (probably latter)

* We need some sort of integration with the tabmail component.
  - Extensions might want to show their sidebar only for certain tabs.

Philip Chee has already done a lot of work on this in an extension which should greatly simplify integration.
Flags: blocking-thunderbird3?


11 years ago
No longer blocks: 460252
Want the today pane showing again ;)
Flags: blocking-thunderbird3? → blocking-thunderbird3+
Target Milestone: --- → Thunderbird 3.0b3
Blocks: 460252
Andrew, we want your input on this bug based on your refactoring work.
Assignee: nobody → bugmail
xSidebar seems nice.  If someone could adapt it to something that could land in comm-central and uses the box introduced on bug 460252, that would be great.  (Right now the sidebar is exposed only inside the folder pane multiplexed tab panel.)  Perhaps an option could be added to let it be moved to the right side, if desired?

Once that is done, the sidebar logic could be setup to be a tab listener, and to persist what sidebar is displayed for each tab.  When the tab changes, it could then change the displayed sidebar once more.

If someone is willing to step-up and start work on this, we can probably get it in for 3.0.  But if no one steps up, it is not going to happen and Lightning will have to keep using its workaround.
And I would propose removing the blocking status.
Assignee: bugmail → nobody
Assignee: nobody → dmose
Target Milestone: Thunderbird 3.0b3 → Thunderbird 3.0b4
Whiteboard: [no l10n impact]
The Thunderbird drivers wish to release Thunderbird 3 as soon as possible. As a
result, we feel that this bug shouldn't stand in the way of all the other good
work getting into the hands of users sooner rather than later. Therefore we are
retargeting it for 3.1. See
for more details. The 3.1 release is expected to be a quick release soon after
Thunderbird 3.
Flags: blocking-thunderbird3.1+
Flags: blocking-thunderbird3-
Flags: blocking-thunderbird3+
Target Milestone: Thunderbird 3.0b4 → ---
blocking-thunderbird3.1: --- → beta1+
Flags: blocking-thunderbird3.1+
We want this, but I suspect I won't have a few hours between now and tomorrow to put it together with a test, so moving it out to block beta2 instead of beta1.  Blake, if you or anyone else is interesting in grabbing this bug and running with it either now or in the future, feel free!
blocking-thunderbird3.1: beta1+ → beta2+
We're resetting the blocking flag for 3.1 on this bug and instead setting the wanted-thunderbird+ flag. We have too many blocking-3.1 bugs, to the point where it doesn't mean much, and managing the list is making it hard to actually work on closing bugs, which helps no one.

Thunderbird 3.1's primary purpose is to allow us to offer a prompted major update to Thunderbird 2 users, to ensure their continued ability to safely use Thunderbird.  Thunderbird 2 is built on an outdated version of Gecko, and our long-term ability to maintain the users' safety for Thunderbird 2 users is limited.

If you think this bug meets the requirements below, please renominate with a detailed explanation of how it meets the following two criteria, and we will reconsider.  To qualify, this bug must either:

a) make the upgrade experience from TB2 very painful for a large number of users


b) be a new, reproducible, severe quality issue (eg dataloss, frequent crashes)

Just because this bug doesn't block TB3.1 doesn't mean it can't or won't make the release.  Once they're done with their blockers (if any), we encourage developers to keep working on non-blocking bugs, and to try to land them as early in the cycle as possible, as non-blocking bugs will become increasingly difficult to land in the later stages of the cycle.
blocking-thunderbird3.1: beta2+ → ---
Flags: wanted-thunderbird+
Assignee: dmose → nobody
Component: Mail Window Front End → Add-Ons: Extensions API
You need to log in before you can comment on or make changes to this bug.