A number of traditional extensions use the XUL sidebar API to create Firefox sidebars. The Panel API being implemented over in bug 494238 satisfies some of the use cases for sidebars, but it doesn't satisfy all of them, since panels are transient model dialogs that appear over (and thus obscure) other application chrome and web content, while sidebars are semi-transient fixtures of the application chrome that don't appear over other chrome/content and thus can be left open by a user performing other tasks. One good use case for a sidebar is to provide a user with ambient access to her lifestream (and those of your contacts) while she is performing other tasks (à la Yoono and Snowl). Another is to provide itermittent access to some popular task (like eBay Sidebar for regular ebayers) or a task that one performs on the current page (as with iMacros, Content Preferences, and Scrapbook Plus). To support these and other use cases, the SDK should include a sidebar API as one of its core modules. The experimental prototype included sidebar functionality via its slidebar API, but for this implementation we should make something that is compatible with Firefox's existing XUL sidebar API, except that it should of course be as easy to use as other SDK APIs and as E10S-compatible as the Panel WIP.

This is very important indeed. If you check the Jetpack For Learning Design Challenge, you will see a bunch of use cases with this kind of persistent content area along with the web content. In some cases, the slidebar was used to give a continuous notion to represent what user is doing. For some other projects, like the one I worked on, the persistent area was used to allow the user to drag content from the main browser area to the addon -- again a kind of persistent notion of the authoring session. And now, that we have much more sites that can actually grant data to be dragged ( not counting the whole on behalf of the user addon-powered experience ) it's a total new world of opportunities for apps where user can capture / transfer live content to the sidebar app content authoring area. -- the following is just brainstorming if we were in the chromeless canvas-browsing space -- I also think that in the moving forward, even in chromeless conditions, this notion will keep up as people will need to have multiple content areas floating in their home wallpaper area. So it will be still possible to keep one active addon area open and do the drag/remix of content between them. But then, at that point, I do not think it will be a sidebar notion but perhaps a notion of a content area page that is floating or fixed in the space -- inline locked perhaps under certain layout context.

I totally agree that some sort of sidebar is very important, that does not obscure page content. I wrote the Cohere Jetpack for the Learning Design Challenge. The slidebar was essential as our tool is for annotating the web, connecing those annotations / ideas and also navigating the web through those associations across site. For this our tool needs to sit open along side the currently open websites.

The Add-on SDK is no longer a Mozilla Labs experiment and has become a big enough project to warrant its own Bugzilla product, so the "Add-on SDK" product has been created for it, and I am moving its bugs to that product. To filter bugmail related to this change, filter on the word "looptid".

Marking anything that potentially looks like a feature request as "enhancement", sorry for the bugspam. :)

(Pushing all open bugs to the --- milestone for the new triage system)

Duping to the newer bug that has UX specs attached.