476154 - Add a sidebar container for extensions to hook into

Status: RESOLVED DUPLICATE of bug 1693543

(Thunderbird :: Add-Ons: Extensions API, defect)

Description

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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.


https://addons.mozilla.org/thunderbird/addon/10000

Comment 1

[Magnus Melin [:mkmelin]]

Want the today pane showing again ;)

Comment 2

[David Ascher (:davida)]

Andrew, we want your input on this bug based on your refactoring work.

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

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.

Comment 4

[Andrew Sutherland [:asuth] (he/him)]

And I would propose removing the blocking status.

Comment 5

[Mark Banner (:standard8)]

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 http://ccgi.standard8.plus.com/blog/archives/242
for more details. The 3.1 release is expected to be a quick release soon after
Thunderbird 3.

Comment 6

[Dan Mosedale (:dmosedale, :dmose)]

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!

Comment 7

[Dan Mosedale (:dmosedale, :dmose)]

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

or

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.

Comment 8

[John Bieling (:TbSync)]

With the switch to WebExtensions this must be channeled through a new API. A good candidate is the customUI proposed in bug 1693543.