+++ This bug was initially created as a clone of Bug #836758 +++

Part of this is also deciding how to proceed with Panorama. We could remove it now and try to re-introduce it with a new implementation. We could prepare patches to remove it and replace it with a new implementation, i.e. not shipping a version without Panorama in between.

Tim, am I correct in thinking you're referencing to Bug 989383?

Yeah, and bug 978810. I thought there was another bug as well that deals with the implementation of the new proposal made by Philipp.

Removing it without having a replacement ready would probably cause some unnecessary fuzz. In related news: there's a Firefox UX work week next week and managing tabs is one of the topics. So I am hopeful that we'll have a clear direction after that.

I would be very much in favor of removing Panorama, hopefully soon. I have discovered in working on patches for bug 906076, Panorama is very expensive when doing mid-session browser state changes if tab groups has been initialized. I haven't done any benchmarking, but for high volume tabs, I have observed that having Panorama initialized while switching states negated to a noticeable degree the improvements obtained with virtual tabs (bug 906076), even to the point of freeze-up in some cases. Of course for the user who doesn't use Panorama and never opens up the UI, TabView._window never gets initialized and none of these affects are felt. Removal of Panorama would also quickly eliminate code changes I am having to make in working on patches for bug 906076. In bug 836758 I created a tab groups API addon: https://addons.mozilla.org/en-US/firefox/addon/tab-groups-gbrowser-api/ Since then I have been working on a full-fledged UI addon for this API, based around the design of Tab Groups Helper addon. I would like to suggest that the API be introduced into Firefox code base, rather than being a separate addon. The API I have written is fairly simple, and its functionality is virtually untaxing. It includes a few helper methods for UI authors, and also includes a method for converting Panorama groups to the new API's format. I am very much in support of a central API in the code base, as this gives a common API for addon authors to rally around. As all the code for the API is an xbl extension of tabbrowser, writing a patch for it would be quite easy. I am wondering if I should upload a patch here, or start a new bug for this, since this bug is about converting Panorama to an addon. Tim, please advise. I will upload the xml extension file from the addon which should make it plain what the patch will consist of.

Code from tab groups API addon proposed to be used for creation of Panorama replacement patch.

Comment on attachment 8514983 [details] gBrowser.xml Allasso, thanks for your patch but we unfortunately currently are not at a stage where we can consider landing this. First, we would definitely not want it to be implement as XBL bindings. Second we would have to carefully evaluate what API we want, how we want to expose it, and what functionality of the current API it should cover. We also have no final UX decision on whether we really want to get rid of Panorama/Tab Groups altogether or want to commit to it again. The latter (including landing a version of your patch) would lead to *a lot* of work. A lot more work than it is to just "rip it out" and provide an add-on. Sorry again, I know it must have taken you quite some time to write the patch but please do not spend even more time on it until we get around to make a decision on the way forward.

Thanks Tim, no problem, as I already had written the code anyway for an addon. I am considering taking it out as an xbl extension of tabbrowser so to make it less likely to conflict with other addons. I appreciate the explanation.

WONTFIX, as with bug 836758.