Closed Bug 836758 Opened 12 years ago Closed 9 years ago

Convert Panorama into an add-on

Categories

(Firefox Graveyard :: Panorama, defect)

Product:
Firefox Graveyard
Component:
Panorama
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: ttaubert, Unassigned)

References

Details

Attachments

(6 files, 1 obsolete file)

part 1 - remove browser/components/tabview/ directory
(deleted), patch
Felipe
: review+
Details | Diff | Splinter Review
part 2 - remove themes and styles
(deleted), patch
jaws
: review+
Details | Diff | Splinter Review
part 3 - remove translations
(deleted), patch
Felipe
: review+
Details | Diff | Splinter Review
part 4 - remove traces in browser/ and introduce some new APIs
(deleted), patch
dao
: review+
Details | Diff | Splinter Review
Alltabs menu fixup
(deleted), patch
Details | Diff | Splinter Review
Screenshot of Panorama in use
(deleted), image/jpeg
Details
Attached patch remove Panorama from the Firefox code base (obsolete) (deleted) — — Splinter Review 
Panorama has a very small user base and there's basically no chance that we will enable it by default or even improve its visibility and discoverability anytime soon. In its current form it is indeed quite fragile and causes intermittent test failures here and there when touching platform code. We're not going to spending any time on improving Panorama and its feature or its design and UX - thus it should just be removed from Firefox.

I myself still am a Panorama user and I don't think there's any replacement for it so I think the way to go is to provide an add-on that provides exactly the same feature. It is my belief that this will encourage contributors to help keep Panorama alive because it's much easier to contribute to a self-contained add-on.

I prepared a patch to remove Panorama from Firefox and moved all the code an add-on that provides the same functionality. The add-on does of course only work with the patch applied to a custom build. You can find the add-on here:

https://github.com/ttaubert/firefox-tabgroups

A nice thing would be to automatically install the add-on for existing Panorama users so they would not even see a difference.
Depends on: 726275
Easy patch. All it does is remove browser/components/tabview/ from the code base.
Attachment #708586 - Attachment is obsolete: true
Attachment #708620 - Flags: review?(felipc)
This patch removes the browser/themes/(pin|win|gnome)stripe/tabview/ directories and style rules from some shared files.
Attachment #708624 - Flags: review?(jaws)
Attached patch part 3 - remove translations (deleted) — — Splinter Review 
This patch removes all strings used by Panorama.
Attachment #708627 - Flags: review?(felipc)
This patch does a little more than just remove stuff it also introduces a couple of new APIs to make the add-on work without monkey-patching. Namely:

* browser.js sends a WindowIsClosing event when WindowIsClosing() is called to allow listeners to prevent the events default action and thus prevent the window from closing.

* tabbrowser.xml has freezeTitlebar() and unfreezeTitlebar() methods to prevent the main window's title from changing (while Panorama is showing).

* SessionStore.jsm sends a SSRestoreIntoWindow event to figure out if a window can be used for restoring tabs.

All the other lines that have been removed without being replaced by an API are handled by the add-on itself.
Attachment #708631 - Flags: review?(dao)
Comment on attachment 708624 [details] [diff] [review]
part 2 - remove themes and styles

Review of attachment 708624 [details] [diff] [review]:
-----------------------------------------------------------------

rs=me
Attachment #708624 - Flags: review?(jaws) → review+
I BTW wrote another patch the re-includes all tabview tests and allows us to run them with the add-on installed:

https://github.com/ttaubert/mq-patches/blob/master/firefox-tabgroups-tests

All tests are running without failures.
Attachment #708620 - Flags: review?(felipc) → review+
Attachment #708627 - Flags: review?(felipc) → review+
While I think this is a pretty silly idea and reminds me far too much of Chromium team for my liking(side tabs issue), I'm not gonna bother preaching here because I know it's futile, if you say you'll get rid of it, you will do it. 

My only question is what will happen to the current tabs/groups that are in panorama? I have over 50 tabs spread across a few panorama groups that are there each time I start the browser and I would be pretty damn angry to lose them since I do use them daily.

So, what's the addon gonna do about this? Allow us to migrate the tab groups? Will removing panorama from the code automatically delete all the tabs or will it migrate them all to the main group?
(In reply to A, T from comment #7)
> So, what's the addon gonna do about this? Allow us to migrate the tab
> groups? Will removing panorama from the code automatically delete all the
> tabs or will it migrate them all to the main group?

We'll install the add-on for existing users automatically. Ideally, you'll not notice any difference between the built-in feature and the add-on. The add-on will continue to use the same tab group data we use right now. To be clear, after updating your browser we'll want to make sure there is no data loss.
How will Firefox decide whether to install the Panorama add-on?
Silly enough！Why not smash whole firefox into pieces (addons) ?!
(In reply to Jesse Ruderman from comment #9)
> How will Firefox decide whether to install the Panorama add-on?

We haven't decided on that part, yet. These patches here will not land before we have a strategy.
He won't benifit sth. meaningful ,but we will lose a lot valuable!
Thousands of great addons will have to be rewritten. 
He just don't want see it so give an option in about:config to hide it from his eyes  instead of totally removing it.
"Hide & show" is very flexible but "remove" will ruin a piece of artwork which a few people is not able to appreciate it!
Panorama let many people cheer when it was introduced!
Really really don't want to see this great thing disappear!
I do not think this is a right thing to do. Panorama is a great feature. But if a great feature is not properly executed of course it won't be a success. The least that could have been done to aid discoverability would have been to keep its button visible by default. But it is hidden right now, of course people do not know the feature exists. A few more feature additions and the feature would become even more powerful than it is today. I don't know why the team doesn't wish to improve it, it is a defining feature of firefox which separates it from all other browsers.

First not working on it and then complaining and removing it seems very short-sighted and a disappointment from firefox team.

I have used the feature to organize my research and manage up to 400 tabs at one point.Given our browser centric lives, a built in tool to manage tabs is a must. People are not using it because it hasn't been promoted at all by firefox.
(In reply to Tim Taubert [:ttaubert] from comment #8)

> We'll install the add-on for existing users automatically. Ideally, you'll
> not notice any difference between the built-in feature and the add-on. The
> add-on will continue to use the same tab group data we use right now. To be
> clear, after updating your browser we'll want to make sure there is no data
> loss.

What will happen later on, in the case where the browser is updated to a new version but there is no updated-to-be-compatible version of the add-on available yet? Or do you consider a genuine compatibility break in this regard so unlikely as to not be worth expending consideration on?

What is the intended means for other add-ons which interact with Panorama to tell whether it is present, either via this new add-on or via running in a version prior to removal? This one isn't just "poking from a distance"; I'm doing work on an add-on which might need to know exactly that.
What will happen to tab groups when the user opens Firefox in safe mode?
(In reply to Tim Taubert [:ttaubert] from comment #0)
> Created attachment 708586 [details] [diff] [review]
> remove Panorama from the Firefox code base
> 
> Panorama has a very small user base 

Can you define how small?  Did you discover this through TestPilot?  I am not a Panorama user myself either, but we need to plan for impact.
Pardon my ignorance, but wouldn't user prefs still be there even if the feature is removed?  Then the plugin would just respect those user prefs once installed?

If that's the case, then anyone who used it could just install the plugin and very little will have changed, right?

Also, are these prefs that are synched?  And would that create any issues across different versions of the browser with and without panorama integrated?
For part 4 of attachment patch

> browser/components/sessionstore/src/SessionStore.jsm

The tab will be restored as hidden if a tab's session has "hidden" property.
And the hidden tab will not be aware by the user.
I think restoreWindow SHOULD ignore "hidden" property.

Additionally, may remove tabbrowser.hideTab method from tabbrowser.xml
As of the last nightly, the "Group your tabs" button is not responsive anymore. It certainly can't be related to this bug, as nothing seems to have been pushed, but there might be a relationship that I'm missing.
(In reply to Jose Fandos from comment #21)
> As of the last nightly, the "Group your tabs" button is not responsive
> anymore. It certainly can't be related to this bug, as nothing seems to have
> been pushed, but there might be a relationship that I'm missing.

That's the second time I hear of it but I can't reproduce it. Definitely not related to this bug. Can you please file a bug?
Right, added bug 839496 to deal with the Panorama button not responding.
> Panorama has a very small user base and there's basically no chance that we will enable it by default

Sounds vermy much like a chicken and egg problem to me.
Almost everyone I showed Panorama to was impressed by it.
It makes surfing the net context aware.

But Firefox as of today does its very best to hide this feature.
I have to open 19 tabs before the dropdown arow shows which which has a pointer to tab groups.
And even this dropdown of the opened tabs is not known by a lot of people.
So how should a feature hidden so deep be found and used by firefox users?
(In reply to Stefan Fleiter (:sfleiter) from comment #24)
> Sounds very much like a chicken and egg problem to me.

Yes, I agree. Removing it from default builds and turning it into an add-on is the only real chance I currently see to hopefully revive its development and maybe we'll one day see a point where we think it is ready to be a mature feature. Maybe not and it will forever be a great add-on used by some/many people. I certainly hope that a self-contained add-on on GitHub encourages a lot more people to contribute to it.
If Panorama does get moved to an add-on, does that mean that Panorama:Plan
https://wiki.mozilla.org/Panorama:Plan
no longer applies?

Some of the ideas outlined on that page looked interesting, but since they're all about greater integration (and some of them would almost certainly require architectural changes in other parts of Firefox), they don't seem terribly compatible with the idea of having Panorama as a completely optional add-on.
I've been a daily user of Panorama since day one. For my purposes, it get's the job done, though I've always been slightly dumbfounded about the missing feature of being able to select (e.g. with Shift+drag_n_drop) multiple tabs in a given Panorama group in Panorama mode. This would, most importantly for me, allow the user to close a selection of tabs at once.

Prior to Panorama, I've been a grateful user of the "showcase" addon:
https://addons.mozilla.org/en-us/firefox/addon/showcase/
http://showcase.uworks.net/download.html
which allows the user to do just that (inter alia).

I would like to push the idea of "merging" Panorama and Showcase's features & capabilites.

Regarding migration of Panorama into an addon: why not? Don't see any real disadvantage. Plus, given that MANY people just use their browser "as is" without understanding the nuts and bolts, I think it would be desirable to make FF lean by default and have Panorama as an addon available to those who know how to appreciate its virtues!

:-)
(unfortunately, I can't see a way to edit my post, so here's a minor clarification:)

I use _both_ Panorama _and_ Showcase.

 ... and be delighted to (one day) see a powerful, single addon called Panorama-Showcase !
Comment on attachment 708631 [details] [diff] [review]
part 4 - remove traces in browser/ and introduce some new APIs

> function WindowIsClosing()
> {
>-  if (TabView.isVisible()) {
>-    TabView.hide();
>+  let event = document.createEvent("Events");
>+  event.initEvent("WindowIsClosing", true, true);
>+  if (!window.dispatchEvent(event))

Setting initEvent's second argument (bubbling) to true doesn't seem to make much sense given that there's nothing the event could bubble up to from window.

>   _prepWindowToRestoreInto: function ssi_prepWindowToRestoreInto(aWindow) {
>     if (!aWindow)
>       return [false, false];
> 
>+    let event = aWindow.document.createEvent("Events");
>+    event.initEvent("SSRestoreIntoWindow", true, true);
>+
>+    // Check if we can use the window.
>+    if (!aWindow.dispatchEvent(event))

ditto
Attachment #708631 - Flags: review?(dao) → review+
(In reply to yxzivhso from comment #27)
> Regarding migration of Panorama into an addon: why not? Don't see any real
> disadvantage.

The problem is that the add-on might get incompatible when changes are made to Firefox.

It won't be a problem as long as incompatibility with the addon is considered as a reason for Aurora/Beta backout.
Will there be an easy way to detect whether Panorama is available or not?  Currently my addon assumes it's there as it's been there forever.
(In reply to Michael Kraft [:morac] from comment #31)
> Will there be an easy way to detect whether Panorama is available or not? 
> Currently my addon assumes it's there as it's been there forever.

Yes, |if ("TabView" in window) { ... }|.
What will happen to users tabs that currently use the panorama feature when this bug lands? Will they all be merged into a single group, or will the users lose their tabs?
(In reply to Scott Johnson (:jwir3) from comment #33)
> What will happen to users tabs that currently use the panorama feature when
> this bug lands? Will they all be merged into a single group, or will the
> users lose their tabs?

See comment 0.
(In reply to Blair McBride [:Unfocused] (Back from the dead. Mostly.) from comment #34)
> (In reply to Scott Johnson (:jwir3) from comment #33)
> > What will happen to users tabs that currently use the panorama feature when
> > this bug lands? Will they all be merged into a single group, or will the
> > users lose their tabs?
> 
> See comment 0.

No, comment 0 doesn't say about tabs.
And attached patches also don't take care of hidden tabs.
Hidden tabs will restored as hidden tab forever (I already mentioned at comment 20 )
(In reply to teramako from comment #35)
> (In reply to Blair McBride [:Unfocused] (Back from the dead. Mostly.) from
> comment #34)
> > (In reply to Scott Johnson (:jwir3) from comment #33)
> > > What will happen to users tabs that currently use the panorama feature when
> > > this bug lands? Will they all be merged into a single group, or will the
> > > users lose their tabs?
> > 
> > See comment 0.
> 
> No, comment 0 doesn't say about tabs.
> And attached patches also don't take care of hidden tabs.
> Hidden tabs will restored as hidden tab forever (I already mentioned at
> comment 20 )

I think perhaps Blair meant that the Panorama feature was going to be removed, but current users of Panorama would be automatically converted to using the add-on, which is really a nice idea. This would solve the problem I was thinking about.
(In reply to Scott Johnson (:jwir3) from comment #36)
> I think perhaps Blair meant that the Panorama feature was going to be
> removed, but current users of Panorama would be automatically converted to
> using the add-on, which is really a nice idea. This would solve the problem
> I was thinking about.

That is the plan, exactly. We're not quite sure how to do that - that's why this hasn't landed, yet.
(In reply to Scott Johnson (:jwir3) from comment #36)
> I think perhaps Blair meant that the Panorama feature was going to be
> removed, but current users of Panorama would be automatically converted to
> using the add-on, which is really a nice idea. This would solve the problem
> I was thinking about.

yeah, I got it. Thank you.

I have new worry. I'm Pano [1] which is depending Panorama APIs author. The Pano users can use Panorama of add-on version, but new users who have not use Panorama cannot use Pano.
Should I create a new add-on packaging Panorama for new users ?

[1]: https://addons.mozilla.org/ja/firefox/addon/pano/
Does this has already pushed somehow to Firefox 19? Ubuntu has upgraded to FF 19 and now Ctrl+Shift+E does not work. The dropdown menu shows the Group Tab item, but clicking on it does nothing.

Does the "Panorama" addon is already released in the addons site?

Best regards,
Manuel.
(In reply to Manuel Vázquez Acosta from comment #39)
> Does this has already pushed somehow to Firefox 19? Ubuntu has upgraded to
> FF 19 and now Ctrl+Shift+E does not work. The dropdown menu shows the Group
> Tab item, but clicking on it does nothing.

Nothing landed so far and this should work with Ubuntu's Firefox.
No wonder that Panorama has so little user base, as:
1. its GUI is so unfriendly (IMO, various tab-grouping plugins are more usable)
2. the feature has no public API (AFAIK)

But I don't understand why are you removing the feature completely. In my opinion its (wasted) potential was as a core functionality for various tab-grouping plugins - if only it was well tuned and had a good public API. 

Nowadays, each tab-grouping plugin groups the tabs its own way, and each one has to solve e.g. tab groups persistence. This results in that the plugins are mutually incompatible, cannot be combined and grow huge and complex. This is what is missing in Firefox APIs, and this could have been the role of the Panorama feature - the unification and a toolbox for tab-plugin developers. Then, the tab plugins could be light-weight superstructures over this core Firefox functionality.

I'm glad that I found this bugzilla defect (by chance) before creating my own plugin based on the Panorama functionality. :-((
I think a good way to frame the previous comment is "in what way can Firefox facilitate a common tab groups structure that the plug-in ecosystem can build on?" That, I think, is the sort of thing that does make sense to have in the core somehow, even if the specific Panorama UI is not.
Blocks: 864065
No longer blocks: 864065
Depends on: 864065
Please consider converting Panorama into this Add-On:
https://addons.mozilla.org/en-us/firefox/addon/tabgroups-manager/reviews/

This is what Panorama should have been.
It's very intuitive and extremely useful.
(In reply to JK from comment #30)
> The problem is that the add-on might get incompatible when changes are made
> to Firefox.

That's the point - if there isn't enough demand to keep it maintained, then it'll die naturally. Right now, developers are forced to keep it working whether it is used or not.

Of course it's "essential" for you, but there aren't enough people who share your viewpoint to make it a wise use of developer time.
(In reply to fawer from comment #44)
> (In reply to JK from comment #30)
> > The problem is that the add-on might get incompatible when changes are made
> > to Firefox.
> 
> That's the point - if there isn't enough demand to keep it maintained, then
> it'll die naturally. Right now, developers are forced to keep it working
> whether it is used or not.
> 
> Of course it's "essential" for you, but there aren't enough people who share
> your viewpoint to make it a wise use of developer time.

Actually, that's totally wrong. The benefits are containment and modularity. So nevermind on that.
So what is the status on this? When it is coming to stable? What will the replacement addon be called?
I created Bug 865594 for a method to approaching the removal and providing a low level API that add-ons can integrate into. 

Is this a viable solution or do you intend to do something else?
I see that this is being removed from the browser, so for users who actually utilize this, how best to go about changing this addon? Apply patches to the current code or wait until the code is patched out?
Wow just wow... Removing one the single greatest parts about the current Firefox.

>"The add-on does of course only work with the patch applied to a custom build. You can find the add-on here:
>
>https://github.com/ttaubert/firefox-tabgroups
>
>A nice thing would be to automatically install the add-on for existing Panorama >users so they would not even see a difference."

Well sounds like either time to stop updating Firefox or hope this "plugin" stays updated...
> Panorama has a very small user base

Do you have actual numbers to quote?

I had a quick look at Telemetry. Now it's not exactly easy to read, but if I'm reading this report correctly (http://goo.gl/6p0gX - login required) the number of users with exactly 1 panorama group is below 50% on Firefox 20. That's... a lot of Panorama users.
Just repeating comment 44:

Please consider converting Panorama into this Add-On:
https://addons.mozilla.org/en-us/firefox/addon/tabgroups-manager/reviews/

This is what Panorama should have been.
It's very intuitive and extremely useful.

Best part is that (either by design or chance), its groups correspond exactly to the Panorama groups so it's already more than halfway there.

Some development work already going on?
https://forums.mozilla.org/addons/viewtopic.php?f=23&t=12202
https://forums.mozilla.org/addons/viewtopic.php?f=7&t=14243
(In reply to bug.zilla from comment #51)
> Just repeating comment 44:
> 
> Please consider converting Panorama into this Add-On:
> https://addons.mozilla.org/en-us/firefox/addon/tabgroups-manager/reviews/

Nop, tabgroups already exits is redundant create another plugin that do the same.
So if they are going to make panorama a plugin I hope that works exactly the same as now.
> 
> This is what Panorama should have been.

Not for me, Panorama is Panorama and it is perfect for me, and tabgroups is not what I want.


> It's very intuitive and extremely useful.

It isn't intuitive for me. I prefer panorama.

> 
> Best part is that (either by design or chance), its groups correspond
> exactly to the Panorama groups so it's already more than halfway there.
> 
> Some development work already going on?
> https://forums.mozilla.org/addons/viewtopic.php?f=23&t=12202
> https://forums.mozilla.org/addons/viewtopic.php?f=7&t=14243

Good for you.
So clearly this is going forward as planned. Is nobody going to answer the question of how many people are thought to be using this feature?

It's been asked twice, and ignored twice. When I asked this in comment 50, I offered some data I pulled off metrics.mozilla.org (Telemetry) suggesting that it may be used a lot.

So, is it really little-used (show numbers?) or is this just a wild guess based on personal observations of Mozilla devs?


If this is being removed for reasons other than low use, why not make that clear? "Lots of people love this feature but we're going to remove it anyway because it's a PITA to maintain." That would at least be honest.
(In reply to Roman from comment #53)
> So clearly this is going forward as planned.

No significant work related to this bug has taken place since it was filed 5 months ago, actually - other priorities have kept us busy. Don't mistake bug discussion for development activity.

> It's been asked twice, and ignored twice. When I asked this in comment 50, I
> offered some data I pulled off metrics.mozilla.org (Telemetry) suggesting
> that it may be used a lot.

Comments on this bug have largely been ignored because we have not been pushing this project forward - don't take it personally :)

re: comment 50, you've interpreted that telemetry data incorrectly, unfortunately. PANORAMA_GROUPS_COUNT is only reported once Panorama has been activated, so it's a measurement of group counts for all *Panorama* users, not a measure of group counts for all Firefox users.

You can see from the "sample size" numbers in the evolution chart you link to (hover over the dots) that these reports are based on samples of ~1000-3300 reports. If you compare that to the sample size of a measurement that is submitted for all users - for example, NEWTAB_PAGE_ENABLED, you'll see that the sample size there is approximately 1.5 million reports. Given those numbers, you could estimate that a maximum of 0.002% of telemetry reports are from Panorama users. Factor in Telemetry's sampling bias, and the real percentage of all of our users that use Panorama is likely smaller than that.

(That wasn't a very rigorous measurement - when we actually do pursue this, we'll likely do a more thorough analysis of the data to confirm. But it's kind of a no-brainer, intuitively, that it is currently vastly underused, given its current discoverability.)
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #54)
> you could estimate that a maximum of 0.002%

Sorry - I did the math wrong here. I meant 0.2%
(The conclusion is also somewhat unsound for other reasons - "number of telemetry reports" is not the same as "number of users" exactly, etc. But it's still illustrative, and like I said my comment 54 is not meant to be a final justification.)
Fair enough, thank you. Having the data makes it easier to feel that this is given proper consideration based on facts rather than guesses.

When you do come back to this to make the final decision, please keep in mind that the 0.2% (or whatever more accurate number you get) are people who use it despite it being essentially invisible in the UI.

A visible feature used by 0.2% might not justify large amounts of fragile code, but for a hidden feature this could mean that lots of people are simply missing out on something they would use if only they knew about it.
I start to think about a fallback if ever Panorama was not developped anymore (who knows).

Maybe some readers here would be interested to know that some users [1] have created differents profiles and use Sync between them (for passwords, addons... whatever you want except opened tabs of course) to handle differents groups of tabs by activities.

Then an extension like ProfileSwitcher allow to easily launch another profile, or you can create different launchers.

You can even use skins to help to distinguish between profiles.

There is still a drawback : you can't easily re-order tabs between profiles like you use to do with panorama groups of tabs

[1] for an exemple in french : http://macsim.labolinux.net/2012/02/comment-je-gagne-du-temps-avec-les-profils-de-firefox/
I think it was easy to be half-hearted about Panorama given the implementation. There were glaring usability issues. However I think most could be fixed by moving the tab groups to the cloud rather than having them locally. It'd be a much nicer implementation by default as it'd be not only available across windows, but also across computers and devices. That in itself would be more marketable than what we have and a much simpler concept to introduce non-power users to.
Nearly everyday I meet people who don't know panorama but who like the idea. So I guess many more people would use this if it would be better promoted.
(In reply to Paul [sabret00the] from comment #59)
> I think it was easy to be half-hearted about Panorama given the
> implementation. There were glaring usability issues. However I think most
> could be fixed by moving the tab groups to the cloud rather than having them
> locally. It'd be a much nicer implementation by default as it'd be not only
> available across windows, but also across computers and devices. That in
> itself would be more marketable than what we have and a much simpler concept
> to introduce non-power users to.

There was a motion in Bug 611194 to merge windows and tab groups into one concept, on that base I propose to introduce a way to hibernate windows (Bug 865594) effectively making them tab groups. 

I think clarifying the concept of a tab group as a window would cater more to non-power user than the current (or any other) porposal while ironing out the quirks that Panorama currently has, even for power users. 

The question remains if this concept is still something the core product would benefit from, or if this rather be packaged as an add-on. While I originally voted for Panorama being a first-class Firefox feature, I'm no longer sure if this brings any benefit; apart from having such a feature as a differentiator against the other browsers.
I use, and to some extent maintain, an add-on which needs to operate on "all visible tabs".

In Firefox 3.x and in Seamonkey (without Panorama), this is done by iterating over tabbrowser.mTabs.

In Firefox 4 through the present (with Panorama), this is done by iterating over tabbrowser.visibleTabs.

At present, I am operating on the hypothesis that once this removal and its associated add-on are implemented, it will be safe to determine which one to use by simply checking for the existence of tabbrowser.visibleTabs.

That is, approximately:
  if(tabbrowser.visibleTabs) {
     "Either this version of Firefox has Panorama in the core, or the Panorama add-on is installed. It is safe to use visibleTabs."
   } else {
     "This version of Firefox does not have Panorama in the core, and the Panorama add-on is not installed. It is safe to use mTabs."
  }

Is it safe to assume that this is / will be correct, at least as far as the scope of this bug goes? If not, what method should I plan on using to determine what to operate against, for any given install?
Since visibleTabs doesn't make sense without Panorama, it sounds like that API should go along with the rest of its code. In that case your sample code should work as you expect. We should wait for a patch to be sure, though.
visibleTabs is there to stay along with the hideTab/showTab API. If you want to detect Panorama, you should look at window.TabView. That said, it doesn't look like you actually want to detect Panorama, you just want to use visibleTabs, and of course it makes sense to just check tabbrowser.visibleTabs to detect this.
Well, in a case where it's known that mTabs will contain only tabs which are visible, I could in theory use simpler and less inefficient code; visibleTabs behaves differently in, IIRC, two important respects.

That said, in practice maintaining two separate code paths would probably be brittle and hard to read; it's probably easier overall to just use the same code for both cases. Thanks for making a definitive statement on the subject.


I'm a bit confused by the idea that visibleTabs might be used or useful for something other than Panorama, and I haven't been able to find any documentation or helpfully clear discussion related to the subject, even with your hideTab/showTab reference as a hint.

Is there anything you could point me to (possibly off-bug) to help clear up that confusion? There's a chance that I may be making unwarranted assumptions about visibleTabs, which have only been true in testing to date by pure chance, and if so I may well need to change my design somewhat.
Just make sure that when I update to the version with Panorama cut away - automatically download and install that add-on or I will come to your house and eat your children.
Anyone know which Firefox version will be the first to have tab groups removed?
This is not actively being worked on at the moment. You'll see progress here should this once be ready to land in Nightly.
That is actually very good to hear. I would personally prefer tab groups to remain a standard, official feature in Firefox.
*Bump*

Just curious if there is any concensus if this is going or staying yet. I would still very much like to see it stay, as it would make it easier for current plugin development, but again this situation is undesirable thanks to the resulting tentative APIs.

It sounds as if it is staying though.
It's neither going away nor is it getting fixed before someone assigns this to him. Basically, it's there, known to be buggy thus not recommended for the broader population, and will get converted into an addon and removed from Firefox some time. For now, it stays because there is other more important work to do, and probably will stay for quite some more time. 

Concerning the general path here: 
I'd suggest that after creating the addon, Panorama should stay around for at least a couple of more releases to allow for "bake time" and the users to install the addon (or is there a way for Firefox to enforce installation of an addon?).
You should not remove it, as doing so is pointless. so just leave it on.
It looks like these patches need updating for the new build system - it still uses the old Makefile.in method, not the new moz.build files.
Since it's been almost a year since this has been opened, and, by the looks of it, it might as well take a few more for this to deliver, I urge for the developer who resumes this work to reassess Panorama's user base then and confirm if the remotion is justified.

I don't care if this is not the proper place for discussion: I see many here voicing their wanting Panorama to stay (so do I). Seems to me we were not present on the proper discussion but I still believe we should be taken into consideration.

And if all in all it's decided to follow through, please be very careful about the remotion. A huge alert box urging the user to backup everything many many months ahead of the change would be nice for starters - even for the ones who don't update FF frequently.

Or I will make comment 66 look like a compliment
I too, believe that the high end users (tech saavy, many of which may be developers themselves) would like to ability to contribute to an open source add-on that can evolve independently from Firefox.  There are several flaws with this feature and they have NOT been improved.

Despite this I like the usability over traditional bookmarking and folders, especially for important stuff that I will be looking at again soon.

That said, we need some commitment from the core Firefox team to not make this too difficult to maintain with future updates.
Unless somebody picks this up, nothing will change. Please don't comment on this bug if there is no change of the status quo. There is no current commitment for either improving or removing Panorama.  

If, however, you are willing to write an addon that replaces (and fixes) Panorama, feel free to start ASAP, and that will not mean that Panorama will be removed anytime soon. If the core functionality of Firefox does not provide what you need, file bugs for new APIs (like Bug 865594) etc. so you can continue your work.
Blocks: fxdesktopbacklog
Whiteboard: [triage]
Assignee: ttaubert → nobody
Status: ASSIGNED → NEW
Whiteboard: [triage]
@Tim Taubert:
I think the main reason it never got wide acceptance was that it was pretty unusable to begin with. I use it daily on all the machines, and the thing I miss badly are basic functionality like multi-selection of tabs, and moving, copying, closing intra & inter tab groups. The bug related to it is https://bugzilla.mozilla.org/show_bug.cgi?id=583435 which is being closed now. If it is improved and advertized properly, people should start liking it as it is a very useful feature.
Whiteboard: p=0
Just to add to the discussion.
Panorama is one of the best features available on Firefox and one of the reasons I use Firefox as my main browser instead of chrome/opera

I would suggest that more features be added to panorama and that the community started to market the features more aggressively instead of removing it from the code base.

Just my 2 cents.
Yes I totally agree with Diogo, I rely on it for my everyday job and I'd really badly miss it if ever it was removed. Even if there are some quirks, they are by no comparison compensated by what Panorama adds to Firefox which you can't find nowhere else. It's certainly not for any users, but for power users it's a must. 

I think it's only the few quirks which discouraged early adopters. Like the automatic replacement when you create a new group, it should be added at the tail and not before the current head (in term of positions viewed from letft/top to right/bottom).

Also sometimes, groups overlap, so it seems you have lost some, but finally they are under another.
I agree strongly with those who argue that this is the closest thing Firefox has to a "killer" feature; you can't find it elsewhere, and once you stumble across it you can't work out how you ever lived without it.  I think it should be core functionality, and should be promoted more (I didn't realize it existed until about six months ago).
Being a seamonkey user and a programmer, I can understand such a feature being migrated to an extension for maintainability.

One advantage is that there can be competing solutions to tab grouping, like there are for many other features.
As well, it seems evident to me that most users would never want such a feature, useful only if one regularly has at least 10 tabs open, more so if one has 50 or more open.

In my case, I would really appreciate a tab grouping extension for seamonkey.  I usually have 60 or more tabs open, which vary a lot over time, and generally fall into 3 or 4 logical groups.
I'm thinking of trying to adapt one of the ff tab grouping extensions to seamonkey.
I don't know how much any ff - sm differences would complicate such a conversion.  Most I've tried only needed adding the sm compatibility paragraph.
I'm not against an addon, I'd just want to be sure it will smoothly take care of what exist (ie does not disturb and keep current panoramas)
Before we actually go so far as to remove the whole thing, I'd like to engage in a "design spike" to see if there's a straightforward and quick path to something we'd consider keeping.
(In reply to Madhava Enros [:madhava] from comment #86)
> Before we actually go so far as to remove the whole thing, I'd like to
> engage in a "design spike" to see if there's a straightforward and quick
> path to something we'd consider keeping.

I think we should remove Panorama and re-land a completely rewritten version with a new design if we can come up with something we all like. If this happens in the same release than we basically have the same effect and can provide a migration path. We really, really should get rid of the current code.
If a redesign and rewrite is possible. Something to consider would be that With the whole Profile in the Cloud push, a panorama that features all tabs across all devices would actually be possible. That'd be a huge boon. It would also be an opportunity to have the feature on mobile devices too, another huge boon.
Now that we understand the possibility space, a clean rewrite is probably a good way to go. I'd recommend starting with a solid data model and a clean separation of concerns between the data and the UI code.

When we originally built Panorama, the data model involved with the UI, so they're all tangled up. Also, we started out managing a single window, but then realized we wanted all windows (and ultimately cloud resources) to be shared. We made an effort to make that happen, but it wasn't possible in the timeframe we had.

Now that we know better the scope, clearly defining the data model should be more straightforward.
Honest question: shouldn't some of this discussion be in a new bug?  The decision was made to remove it.  One thing at a time/one issue per bug?
(In reply to bugzilla from comment #90)
> Honest question: shouldn't some of this discussion be in a new bug?  The
> decision was made to remove it.  One thing at a time/one issue per bug?

Bugs should be about implementation, not debating or discussing a decision; that's why we have mailing lists and newsgroups. Of course not everyone obeys these "rules" nor are they strictly enforced.
Features that would make panorama simpler, more useful, more discoverable, more powerful and likely more popular

1. the panorama name is meaningless, something like "tab groups" gets right to the point
2. the current modal overly graphical panorama ui is largely worthless, thumbnails are useless, titles are more important, the draggable/resizable 2d visualization of groups and tabs is pointless, there is no value in visually reshaping tab groups, they are collections of tabs not a visual presentation requiring WYSIWYG editing, there's also no need to cover the whole browser.  Look at the "tabgroups menu" ui, it allows for creation, (re)naming, switching, closing of groups through a simple, fast dropdown menu, it gets the job done and does not get in your way.
3. persistence is a must, no point in creating multiple groups with lots of tabs with no way to preserve that work - the simplest way to persist tab groups is with bookmarks no need for anything new and complicated.
a1. allow the saving of a single group as a bookmarks folder (named after the group)
a2. allow the opening of a bookmark folder as a group 
b1. allow the saving of all current groups as a folder (named by user) of folders (named after groups)
b2. allow the opening of a folder as a collection of groups (subfolders)
one more persistence feature:

a group saved to or opened from a bookmark folder should remember this fact and allow for fast, single click/action saving
(In reply to bugzilla from comment #90)
> Honest question: shouldn't some of this discussion be in a new bug?  The
> decision was made to remove it.

That's not how Mozilla works. I suggested removing it and proposed a few patches but I can't just decide to remove it on my own. We were and still are undecided about the best way to move forward, that's why this bug is still unresolved.

> One thing at a time/one issue per bug?

Yes, I fully agree with this. If we decide to give a reimplementation a shot then this bug will hold the removal patches. This bug has too many off-topic comments already.
Attached patch Alltabs menu fixup (deleted) — — Splinter Review 
I found that using the supplied patches, the alltabs drop-down menu gets "sticky entries". This patch should fix that. It may not apply cleanly to trunk since I've been working with 24ESR code for this, but should be a required addition for removal of panorama.
(In reply to al_9x from comment #92)
> 2. the current modal overly graphical panorama ui is largely worthless,
> thumbnails are useless, titles are more important, the draggable/resizable
> 2d visualization of groups and tabs is pointless, there is no value in
> visually reshaping tab groups, they are collections of tabs not a visual
> presentation requiring WYSIWYG editing, there's also no need to cover the
> whole browser.  Look at the "tabgroups menu" ui, it allows for creation,
> (re)naming, switching, closing of groups through a simple, fast dropdown
> menu, it gets the job done and does not get in your way.

You're making assumptions based on your use rather than in the best interests of the feature.

First of all, the majority of research contradicts your point regarding lists vs thumbnaiils. It is far quicker to process images than it is text. Also using text would introduce constraints on how many groups can be put side by side.

Tab management is a huge part of Panorama. A static tabs list is really of little value. But a general example is that a user opens a tab in one window and it's useful for another window, the user should be able to move the tab to the other window easily. In this case you have two options, Right click -> Tab Groups -> Desired Tab Group VERSUS simply Drag Out of Tab Strip -> (Visual Tab Groups) -> Desired Tab Group. I'd say the second option is far more useful. Note: Should you be dragging the current tab it should change active tab group and if it's a secondary tab, it should simply stash the tab.

If a user has one or two tab groups with hardly any tabs there could be an argument for non-fullwindow, but what happens if the user has many tabs and many groups? There's also the argument for consistency. And what should be introduced is a single way to manage tabs and switch groups.

It's also worth noting that the Tab Groups Menu is very much mouse driven, we're in an age of moving beyond that. How does your desired approach work for touch based UI? That's a consideration that would need to be thought about.

If Panorama/Tab Candy/Tab Groups/Tab Management are to be rethought, I'd like to see this as a joint project between the Desktop, Mobile and Synch teams and thus enabling a deep and purposeful integration. Detaching a tab currently lacks animation, something that would be nice for a new Panorama. Especially as currently, it's impossible to drag a tab between windows on Linux without first un-maximising the current window. We'd be able to fix the horrible UX here while providing the option to either copy or simply paste to a new window or even another device.

I think you're selling the idea of what Panorama could and should be far too short. It's about centralising a users data. Being able to push, pull and copy tabs from different groups and devices is the absolute minimum. To take this forward would be about realising the potential of visual tab management in the modern reality of browser use. To reiterate, it would consolidate the UX of tab management (Panorama, Sync and simply Switching Windows) along with some menus.

It would also solve the long-standing frustrating bug about closing last window dialog, since you'd introduce the preference to "Keep Group When Closing Window" and could have that set to Prompt, Always or Never".

Regarding the suggestion to rename Panorama, something like Firefox/Tab Overview would be appropriate and would allow for easier promotion of the feature and help for users regarding the feature.
No longer blocks: fxdesktopbacklog
Flags: firefox-backlog+
Depends on: 996874
Whiteboard: p=0 → p=2
I have came up with an idea for a way to improve panorama that includes ideas for mobile, desktop, and synchronization features that will work together to make tab groups a way to easily manage your tabs across all devices if desired, and into what could be a major feature for a considerable amount of people. The bug I filed is bug 999895.
Question, does Panorama refer to the tab grouping engine, or only to the UI?

I developed an addon (Tab Groups Helper) a few months back which provides an alternate interface for native tab groups. (List views, side by side columns, plus other features - see https://addons.mozilla.org/en-US/firefox/addon/tab-groups-helper/)  Like others, the native UI for me was basically worthless, so I developed my own. (Proponents to the graphic idea apparently aren't using 100s of tabs.)

However, since Tab Groups Helper is only an UI, if the native implementation of tab groups (tabview?) is removed, Tab Groups Helper will be worthless.  I would be in favor of removing the Panorama interface, but please keep the native Tab Groups implementation.  If Tab Groups management is going to be deferred to addons, all the work has already been done in Firefox, so it would be nice if addons didn't have to re-invent the behind-the-scenes stuff, and could just focus on UI.
(In reply to Allasso Travesser from comment #98)
> Question, does Panorama refer to the tab grouping engine, or only to the UI?

Sorry to tell you but Panorama is a whole feature, it does not only have a "grouping engine" or only a UI. It's a combination of both. It was never intended to be used like that although we in the past wanted to offer a real API.

We definitely have no plans to keep and support the old API (which isn't an API) as it was never officially supported to develop add-ons against that. Ideally, when reimplementing the feature (iff that happens) we would also develop an official API that add-ons can use to access and manage tab groups, no promises here though.
(In reply to Tim Taubert [:ttaubert] from comment #99)
> (In reply to Allasso Travesser from comment #98)
> > Question, does Panorama refer to the tab grouping engine, or only to the UI?
> 
> Sorry to tell you but Panorama is a whole feature, it does not only have a
> "grouping engine" or only a UI. It's a combination of both. It was never
> intended to be used like that although we in the past wanted to offer a real
> API.
> 
> We definitely have no plans to keep and support the old API (which isn't an
> API) as it was never officially supported to develop add-ons against that.
> Ideally, when reimplementing the feature (iff that happens) we would also
> develop an official API that add-ons can use to access and manage tab
> groups, no promises here though.

Shame I didn't know that when I started.  It would have been *much* easier to create my own system of grouping (basically groups are just tabs that are visible and not pinned, and I even saw a way I could store pertinent data in sessionstore), but I endeavored to keep things in concert with native Firefox code, believing it would be less prone to conflict and extinction later.  It was quite a challenge to decipher Panorama/TabView API (or whatever you want to call it) which seemed very convoluted.  I think a lot of this has to do with the fact that the code for the interface is integrated into the code for managing the groups.

Nevertheless, I still think a central native Firefox API (that Mozilla will be committed to supporting) would be the way to go, if it would be designed with the paradigm of only defining what groups are and how they are stored in sessionstore, and allowing addons to easily plug into it.  The basic API could actually be very simple (please, don't make it unnecessarily complicated).
(In reply to Allasso Travesser from comment #100)
> Shame I didn't know that when I started.  It would have been *much* easier
> to create my own system of grouping (basically groups are just tabs that are
> visible and not pinned, and I even saw a way I could store pertinent data in
> sessionstore), but I endeavored to keep things in concert with native
> Firefox code, believing it would be less prone to conflict and extinction
> later.  It was quite a challenge to decipher Panorama/TabView API (or
> whatever you want to call it) which seemed very convoluted.  I think a lot
> of this has to do with the fact that the code for the interface is
> integrated into the code for managing the groups.
> 
> Nevertheless, I still think a central native Firefox API (that Mozilla will
> be committed to supporting) would be the way to go, if it would be designed
> with the paradigm of only defining what groups are and how they are stored
> in sessionstore, and allowing addons to easily plug into it.  The basic API
> could actually be very simple (please, don't make it unnecessarily
> complicated).

If you modify your extension to be independent of Panorama, it would have a number of advantages :
1) For those who don't want groups, Firefox would be leaner, after Panorama is removed.
2) It would no longer be dependent on anything Panorama does relating to groups.
3) It should be easier to adapt it to other Gecko-based browsers, such as Mozilla Seamonkey.  (That interests me as a Seamonkey user.)
4) It may even be easier to port it to webkit based browsers which implement groups, such as Midori.
5) If someone wants to implement another group UI, they could base it initially on your backend group code.  That could accelerate the removal of Panorama, if the visual paradigm is not simply dropped.

This is assuming that you hook your extension to basic tabs functionality.
In my view the graphical tab view is only useful to those with a very limited number of tabs, and your approach is much more useful.  (Myself I rarely have less than 60 tabs loaded, logically dividable into at least 3 distinct groups.)
(In reply to andré from comment #101)
> If someone wants to implement another group UI, they could base it initially on your backend group code.
My opinion is that it would be better if Mozilla provided the backend code as an API. This would be more reliable than making a particular addon the standard and more likely that addon developers would rally around the same pole and less likely for conflict. The backend should be very trivial, a simple object to track group definitions (ids and names mainly) and serialize it for sessionstore.  The overhead would be inconsequential.

Nevertheless, in preparation of what might come, I am modifying my addon just as you suggested, to be split off as a separate alternate version (probably suffixed with "II").  Now as I think about it, perhaps what I can do is create an addon that would only be the backend API.  This could be used by alternate Tab Groups UI and session management addons and would much less likely become extinct if it was not maintained.
I think that this bug should be marked as depending on bug #697959 (create a tab groups API).  The FIRST step is to create an API that handles tab groups, THEN we can worry about removing the UI.  The foolish way in which this feature was initially added --- mixing the UI and backend and not providing a documented API --- was a huge mistake, and is the reason it has low usage.  Nonetheless, the solution is to step up to the plate, clean up the mess, and provide the real API that should have been provided in the first place.  Trying to hide the mistake by killing the feature would be a weaselly thing to do.  Tab groups are an essential feature for people using more than a few dozen tabs, and including tab group handling in Firefox was a great idea, it was just done in a horrible way.  If a real API is added, then addons can start implementing their own UIs.

The "real API" could be an addon, that's fine.  But the crucial thing is that converting the entire Panorama UI/backend mess into an addon solves nothing.  The problem is that there is no API, and to solve that problem an API needs to be created and detached from the UI.  Then whether this stays in Firefox or becomes an extension is a minor point.
I am very interested in trying to get this api created/fixed - I have a number of sessions in which tabs are trapped because of this, it would nice to be able to liberate them.
Incidentally, we are in the process of adding a clean(er) API for accessing/saving Session Restore data. Once this new API is ready, it will make it possible to avoid a number of Panorama hacks.
(In reply to David Rajchenbach Teller [:Yoric] from comment #105)
> Incidentally, we are in the process of adding a clean(er) API for
> accessing/saving Session Restore data. Once this new API is ready, it will
> make it possible to avoid a number of Panorama hacks.

Right now one of the challenges I am having in developing an API addon is there is no notification sent out when a session restore action is initiated, which can happen in the middle of a Firefox session when using a session saving/management tool.  There are notifications sent when the restore is completed, eg, sessionstore-windows-restored, sessionstore-browser-state-restored, but nothing telling us when the restore action has begun.  As I am relying on tab events eg TabOpen, TabClose, TabPinned etc to update Tab Groups data when these events occur, I need to handle them differently when they are the result of a restore going on.  As it is now, I need to use hacks such as interval timers to avoid inefficiencies created when handling a slew of rapidly opening tabs one by one during a restore of a very large session.

But perhaps the new sessionstore API will offer tools which will allow Tab Groups data updating to be handled altogether differently, via more robust communication with sessionstore.  It would be great if we could closely link the Tab Groups API with sessionstore, and not have to rely on listening for tab actions and guess at what to do with them.  Maybe those are the hacks to which you were referring.

I have always wished that sessionstore could be more open and accessible.
(In reply to smaudet from comment #104)
> I am very interested in trying to get this api created/fixed - I have a
> number of sessions in which tabs are trapped because of this, it would nice
> to be able to liberate them.

If you wish to email me details on your situation, I am willing to help you get your tabs liberated in the meanwhile.
Amending and apologizing for part of comment #105 - I happed upon bug 615394 which revealed that the notifications I am looking for already exist: SSWindowStateBusy and SSWindowStateReady
In a replacement/experimental API addon, is there a problem with TabView = null to quench Panorama methods?  Or is TabView used for something other than Panorama?
Recanting my recant in comment #108 - SSWindowStateBusy and SSWindowStateReady do not exactly fit the bill.  I have filed bug 1037075.
I have created an API that serves as an alternative to Panorama.  This is an API only, no UI.  It extends tabbrowser, and all methods and properties are accessible through the gBrowser global object.

It is intended to override TabView, however does not completely disable it, just (hopefully) disables or circumvents actions which would interfere with this API.

On first enabling it attempts to convert TabView tab groups to "gBrowser tab groups".  Subsequently it will attempt to do the same whenever encountering a mid-session restored state (eg, Session Manager session change) which does not contain gBrowser tab groups data.  It is designed to work seamlessly when restoring a session or window using setWindowState or setBrowserState (which Panorama did not).  It seems to work fine when restoring sessions with Session Manager addon.

See the addon page for more details on its functions. 

I have also created a demo UI to demonstrate the gBrowser tab groups API.

I would appreciate input on how to insure the extended binding is bound before other addons are enabled.

gBrowser tab groups API:
https://addons.mozilla.org/en-US/firefox/addon/tab-groups-gbrowser-api/

gBrowser tab groups API demo:
https://addons.mozilla.org/en-US/firefox/addon/tab-groups-gbrowser-api-demo/
Alasso: is your code somewhere it can be looked at/reviewed?
(In reply to  David Rajchenbach Teller [:Yoric] from comment #112)
> Alasso: is your code somewhere it can be looked at/reviewed?

http://kevinallasso.org/gbrowser_tab_groups_api/
I maintain (mostly privately, though I plan to publish it at some point) an extension which needs to be able to operate over the scope of "all tabs in the currently active group".

At the moment, it does this via tabbrowser.visibleTabs, with a fallback to tabbrowser.mTabs if visibleTabs does not exist. It relies on (visibleTabs[i+1] == visibleTabs[i].nextSibling && visibleTabs[i-1] == visibleTabs[i].previousSibling), discounting cases where the nextSibling or the previousSibling tab does not exist.

Is this expected to continue to work as a means of operating over that scope under the tab-groups API you propose, or does the new API also effectively provide a new definition of "the currently active group" which would require a third operation mode?
Andrew (comment 114):

My proposed API still uses tabbrowser.visibleTabs.  It is designed to integrate with existing tabbrowser functionality.  The exception to this is showOnlyTheseTabs, which is overridden to disable Panorama functionality.  AFAICT, showOnlyTheseTabs is currently only used by Panorama.
Andrew (comment 114):

I can't speak for whether or not visibleTabs will be removed from Firefox by Mozilla.  The proposed API does not depend on visibleTabs, it only uses measures not to break it.
Per comment 64, someone who very probably can speak for Mozilla in that regard has said that visibleTabs is here to stay even without Panorama. I was mostly concerned about whether visibleTabs would continue to correspond to "the currently active tab group", which apparently it will.
(In reply to Allasso Travesser from comment #111)
> I have created an API that serves as an alternative to Panorama.  This is an
> API only, no UI.  It extends tabbrowser, and all methods and properties are
> accessible through the gBrowser global object.

Very interesting!  It might be helpful if you could create a Bitbucket or Github project for it so that people could raise issues, submit contributions, etc.
What is with Bug 697959? There was a API prepared in 2012. 

Its frightening that self the developers here forget their projects to push to a good end. Up to the next 2 years...
Points: --- → 2
Flags: qe-verify?
Whiteboard: p=2
> https://github.com/ttaubert/firefox-tabgroups

The provided add-on URL is no longer alive. Has the add-on idea been cancelled?
FWIW, Microsoft's new Spartan browser will have tab groups [1].

[1] http://www.theverge.com/2015/1/8/7516489/windows-10-new-browser-spartan-features
(In reply to Sören Hentzschel from comment #121)
> FWIW, Microsoft's new Spartan browser will have tab groups [1].
> 
> [1]
> http://www.theverge.com/2015/1/8/7516489/windows-10-new-browser-spartan-
> features

Hopefully a more mature implementation than what's been sitting in the Mozilla code base. IMHO it should either be implemented properly or externalized into an add-on.
(In reply to Robert Orzanna from comment #120)
> > https://github.com/ttaubert/firefox-tabgroups
> 
> The provided add-on URL is no longer alive. Has the add-on idea been
> cancelled?

Tim, may you shed a light on this?
Flags: needinfo?(ttaubert)
(In reply to Florian Bender from comment #123)
> (In reply to Robert Orzanna from comment #120)
> > > https://github.com/ttaubert/firefox-tabgroups
> > 
> > The provided add-on URL is no longer alive. Has the add-on idea been
> > cancelled?
> 
> Tim, may you shed a light on this?

Sure. The repo was removed only because it was heavily outdated and I didn't want to give people the impression that it still worked. I would need to start from the beginning again here and wouldn't want to do that before there is any consensus on the way forward.
Flags: needinfo?(ttaubert)
Noooo please don't remove Panorama from Firefox. 

I am a heavy user of Firefox + Panorama. I have 70-100 tabs across ~15 tab groups most of the time. It helps me keep organized, while keeping issues I need to work later on in the back burner. It is one of the main reasons why FF is my main browser, since all the others don't handle nicely or simply crash 15+ tabs..

By making it a plug-in I am afraid it will prone to compatibility issues with other add-ins and FF itself in the future.
(Have not read the whole thread, just some of it and skimmed a lot, apologies if that's bad form, not sure.)

Just an FF user here with my 2 cents of feedback (all of which, of course, is "imo"):

I can't believe FF would take a great feature and then just dump it instead of fixing it.

- Panorama sounded amazing to me when it came out, a really useful feature, the future of browsing even.

- I VERY eagerly wanted to use it from the beginning until I found out it doesn't work across all windows and has no persistence. So I ended up never even bothering to use it because without those features I find it to be basically useless as it was in no way more convenient. 

- You can't "explore/use your tabs in a new way" without those features (at least consistently while being enjoyable).

- I fully agree with al_9x's 1st & 3rd points in comment 92.

So I've been waiting on word of fixes or improvements to Panorama since forever and then instead of that I see this..

It's really crushing to see, as a stalwart FF fan and proponent of the browser. I mean, in so many other ways over the years (less so lately, thankfully) FF has seemed to lag behind Chrome for exciting new features and here was one brilliant idea Mozilla had that no one else did and it was released half-baked, then allowed to rust instead of being fixed, and now apparently the plan is to just scrap it, instead of finally retooling it.

- If you guys had fixed this feature (and, imo, implemented it properly in the first place) I still think you would have a real mindshare grabbing flashy feature on your hands.

(Though obviously any future retool, should it happen, should be renamed, because any "Panorama" news I think would just automatically get associated in people's minds as vaguely remembering something "half-baked" and "abandoned".)

- (I grant that this may be a complex and difficult issue to solve, and that I have no knowledge of what that entails.. but, nonetheless, the expectation still remains.)

***

TL/DR:

- If it's not a priority for Mozilla to fix/implement properly any time soon than I suppose it may as well be removed/become an add-on.

- I just hope that at some point you will see the value in implementing this feature in less of a proof of concept manner and more of a "geared to actual daily usefulness for users" manner (as mentioned above).*

*And do so especially quick if MS's Edge browser ends up implementing something similar to this.

[Note: I did not mean any of this to be disparaging to anyone's I'm sure hard work on this feature, just to convery my dissapointment at the decision making process around it.]
Finally, many years after we were pretty sure we were going to remove panorama... we are actually doing it. We won't move it to an add-on, so I will close this bug as wontfix and actually do the removal in bug 1221050.

For some rationale:
- usage is now at some 0.01% of users (bug 1210773 comment 6) and falling. That is very very low - in fact, it seems plausible that usage of several external tab management add-ons is higher.
- its code and how it does things is actively problematic for our work on other projects, such as e10s, and complicates many other things such as theming and our automated tests.
- the quality of the feature isn't what we would like it to be, and the quality of the code for the feature itself has suffered, too: we would likely do things differently if we rewrote it today. Even if we wrote something else in this space, the current code would not be much use.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Summary: Convert Panorama into an add-on and remove it from Firefox → Convert Panorama into an add-on
Tim, any chance you could reopen your github project, with at least a high-level overview of how you think this feature could be reimplemented as an add-on?
Flags: needinfo?(ttaubert)
My GitHub project merely moved all the code into an add-on, it wasn't a lot of work to do that - but I don't have that code anymore. Panorama is basically still in the shape of an add-on, with XUL overlays etc. bringing it back is doable.
Flags: needinfo?(ttaubert)
So, bug #996874 (Breakdown: Convert Panorama into an add-on and remove it from Firefox)should be resolved as wontfix too?
Does anyone know of anything that provides similar functionality?

I find this feature very useful and have gotten used to it.
For the record, here's my repo based on Tim's work with a few fixups.
Although, if XUL is going to be removed as a technology in Firefox, it will likely have limited shelf-life for it.

https://github.com/wolfbeast/palemoon-tabgroups
(In reply to 6lobe from comment #131)
> Does anyone know of anything that provides similar functionality?
> 
> I find this feature very useful and have gotten used to it.

I'm trying https://addons.mozilla.org/en-us/firefox/addon/tab-groups-helper/
(In reply to Jacques Le Roux from comment #133)
> (In reply to 6lobe from comment #131)
> > Does anyone know of anything that provides similar functionality?
> > 
> > I find this feature very useful and have gotten used to it.
> 
> I'm trying https://addons.mozilla.org/en-us/firefox/addon/tab-groups-helper/

Tab Groups Helper is only an alternate UI for Panorama.  TGH relies on Panorama for the backend.
Yes I had just understood that before receiving your message. Does it means that also the data struture will disappear or only the Panorama UI? If all disappear, what would be a reliable alternative?
The structure of the groups will definitely disappear.  I assume the tabs will all remain, although all of them would be visible as if in a single group.  This is just an assumption though, Tim or Gijs should be able to give a better answer.

I am not familiar enough with other tab group management addons to know if they provide their own backend or not.
This "tabs of tabs" addon (https://addons.mozilla.org/en-us/firefox/addon/tab-group-bar/) is very user friendly, as the tab groups are always visible, although it too relies on the underlying Panorama groups.
probably all existing tab group extensions rely on the panorama backend, and it should not be removed without a replacement.  Panorama interface deficiencies notwithstanding, the core concept, switchable groups of tabs makes a lot of sense and is a natural extension for a tabbed browser, so experimentation here should be facilitated
Wouldn't it be possible to just move the existing tabgroup code, already externalized in the repo I pointed to, to the extensions that rely on this code? 

Practical experience using the add-on has shown successful interaction with other extensions that talk to this code, so it should be simple enough, if people don't want to reinvent the wheel, to supply the Panorama code in their extensions that currently build on this code being in the core.
The extension also preserves existing groups after removal of the code from the core (which we've done quite a while back in our builds) as long as the session data is preserved.
I have asked Allasso Travesser if he will take over, not sure about that yet: https://addons.mozilla.org/fr/firefox/addon/tab-groups-helper/#reviews
Oops, just realised you (Allasso Travesser) answered to me above :)
Note that Session Restore sill supports hidden tabs, which I believe are the only back-end feature really needed for Tab Groups.
Yes, but that does not give the tabs groups structure I guess?
(In reply to al_9x from comment #138)
> probably all existing tab group extensions rely on the panorama backend, and
> it should not be removed without a replacement.  Panorama interface
> deficiencies notwithstanding, the core concept, switchable groups of tabs
> makes a lot of sense and is a natural extension for a tabbed browser, so
> experimentation here should be facilitated

I second that this feature should not be removed unless there is a replacement option available, no matter how simple it is. At the very least it should not lose existing tabs when upgrading to a version of FF without tab groups.
Attached image Screenshot of Panorama in use (deleted) — 
Excuse me if this is bad bugZilla etiquette. I just wanted to thank you for the great feature that you are about to discard. I am an avid Panorama user (see screen-shot, 114 tabs, 11 tab groups).

As other fears, I too don't think that an Add-on will replace the Panorama functionality to a full extent. So I might just stay with the latest FF version that will support it.

I am using other Add-ons to manage my tabs (Tab Mix Plus for session Management, Multiple Tab Handler for tab arrangement, .. ) but none has proven to provide Panorama's capability.

I know we are not many users, but then again, why downgrade a product?

Thanks again.
It's a shame this feature is going to be scrapped (with no replacement, too!) Been using Firefox since version 1.0, but will probably move on to Chromium as my main browser when this is removed.

The concept of Panorama is spot-on and very useful. Organizing tabs into groups by topic is invaluable for power users doing a lot of research online. 

Interestingly enough, while Panorama is being discarded, Chromium offers an addon that works in a similar vein and has over a hundred thousand users and many positive reviews: http://lifehacker.com/tabs-outliner-keeps-track-of-all-your-tabs-in-an-easy-t-485785650
(In reply to :Gijs Kruitbosch from comment #127)
> - its code and how it does things is actively problematic for our work on
> other projects, such as e10s, and complicates many other things such as
> theming and our automated tests.

This is what worries me the most. The dev team are modifying Firefox in ways that are "problematic" for this feature, which I understand to mean "incompatible with it in its current form". So once the feature is dropped, Firefox will be modified as planned, and existing Panorama code will stop working even if someone took the time to spin it out into an addon.

I do believe there is a lot of use for a feature that hides tabs not relevant to the user's current activity. Panorama may have some UI or coding shortfalls, which are possibly part of the reason why it's not in widespread use. But it's important to keep the infrastructure in place so that addon authors can continue experimenting with the best UI for this feature in a way that is compatible among multiple such addons.
(In reply to Roman from comment #148)
> (In reply to :Gijs Kruitbosch from comment #127)
> > - its code and how it does things is actively problematic for our work on
> > other projects, such as e10s, and complicates many other things such as
> > theming and our automated tests.
> 
> This is what worries me the most. The dev team are modifying Firefox in ways
> that are "problematic" for this feature, which I understand to mean
> "incompatible with it in its current form". So once the feature is dropped,
> Firefox will be modified as planned, and existing Panorama code will stop
> working even if someone took the time to spin it out into an addon.
> 
> I do believe there is a lot of use for a feature that hides tabs not
> relevant to the user's current activity.

This API (a distinction between all tabs in a <tabbrowser> and visible/hidden tabs) is not being removed, as has been mentioned elsewhere in this bug.
(In reply to :Gijs Kruitbosch from comment #149)
> This API (a distinction between all tabs in a <tabbrowser> and
> visible/hidden tabs) is not being removed, as has been mentioned elsewhere
> in this bug.

Frequent code breakages are cited as one of the reasons for Panorama removal.

How is that possible, then, if Panorama only depends on some API that's going to remain stable?
(In reply to Dmitry Gutov from comment #151)
> (In reply to :Gijs Kruitbosch from comment #149)
> > This API (a distinction between all tabs in a <tabbrowser> and
> > visible/hidden tabs) is not being removed, as has been mentioned elsewhere
> > in this bug.
> 
> Frequent code breakages are cited as one of the reasons for Panorama removal.
> 
> How is that possible, then, if Panorama only depends on some API that's
> going to remain stable?

I did not say that Panorama <only> depends on this API, and it doesn't - it uses/does a lot of other stuff, like hiding the entirety of the rest of the browser when managing tabs, and using 2d coordinate space to group tabs, and storing data in JSON strings and have comparatively inefficient data mechanics when you don't care about the 2d coordinate space things.

But comment #148 asked about whether the visibleTabs / tab.hidden API was going away, and I answered that question.
(In reply to :Gijs Kruitbosch from comment #152)

> But comment #148 asked about whether the visibleTabs / tab.hidden API was
> going away, and I answered that question.

Comment #148 was inquiring about feasibility of an Panorama-like addon.

Allow me to rephrase the question, maybe: do you think it's at all possible to rewrite Panorama into an addon that uses stable-ish APIs? So that the author doesn't have to re-tweak its source code for every Firefox release, because that's bound to become exhausting, and a source of bugs?

Because the things you mention (inefficient storage of data) don't sound to me like a plausible source of frequent breakages caused by changes in code external to Panorama (source of other bugs - maybe). But of course I'm just guessing here.
Firefox internals don't have any formal definition of "stable" or "stableish" APIs. Someone maintaining Panorama-as-an-addon should expect that it's generally likely that as Firefox evolves, that will be an ongoing maintenance burden. (See other tab-related addons, which have generally needed frequent updates.)

It would be good for the addon maintainer to work with the WebExtensions team to see about getting actual APIs to support Panorama's use case. Really, this is exactly why we're moving to WebExtensions in the first place. Extensions that just poke directly at Firefox internals are a pain for us and add-on authors alike, for the reasons you describe.
(In reply to Justin Dolske [:Dolske] from comment #154)
> Really, this is exactly why we're moving to WebExtensions in the first
> place. Extensions that just poke directly at Firefox internals are a pain
> for us and add-on authors alike, for the reasons you describe.

Of course apart from ignoring the fact that WebExtensions actually needs an API written per use-case (how many specific APIs are you actually planning to tack on to the WEAPI?) to have an interface to the Firefox internals required for it to function, which will be just as a pain to maintain when the underlying code changes out from under it, and in fact not something extension developers can respond to to fix or work around (because it would be core work) essentially breaking the extension(s) until such time as it's fixed in the API. That just leaves the trade-off of being bound to whatever API is provided versus such an API being less likely to change rapidly, and no clear win. AFAICT, anyway -- feel free to correct me if don't understand correctly.

Either way it'll need a defined/stable API, or at the very least clear documentation, if you want to support extensions that currently build on top of Panorama, regardless of type of extension framework used.
(In reply to Justin Dolske [:Dolske] from comment #154)
> Firefox internals don't have any formal definition of "stable" or
> "stableish" APIs. Someone maintaining Panorama-as-an-addon should expect
> that it's generally likely that as Firefox evolves, that will be an ongoing
> maintenance burden. (See other tab-related addons, which have generally
> needed frequent updates.)

All right.

> It would be good for the addon maintainer to work with the WebExtensions
> team to see about getting actual APIs to support Panorama's use case.
> Really, this is exactly why we're moving to WebExtensions in the first
> place. Extensions that just poke directly at Firefox internals are a pain
> for us and add-on authors alike, for the reasons you describe.

In that case, I'd really be much happier if the Panorama removal were to be delayed until the WebExtensions team adds the relevant APIs.
(In reply to Dmitry Gutov from comment #156)
> In that case, I'd really be much happier if the Panorama removal were to be
> delayed until the WebExtensions team adds the relevant APIs.

^^This would be consequently in background to my comment 119 in this bug... The history show us the API was never introduced. So no firefox dev should claim that addon developers does their own thing in the past with all consequences. With WE we can only beg for support or we can forget it. That is the difference.
I'm really hoping not to lose my well-organized 10 groups of ~120 tabs.

I currently use an addon called "TabGroups Menu", and I have set it such that all 10 of my tab groups display when I click a simple dropdown arrow next to the Panorama button. And it works fine, even in Firefox 42. But it sounds like it might break when Panorama is removed.

I propose that you still keep tab groups, and present a simple clean interface that the "TabGroups Menu" has done. Maybe even incorporate it into the existing Firefox dropdown element, that shows the current group's tabs.

https://addons.mozilla.org/en-US/firefox/addon/tabgroups-menu/
For those unaware… there's already an addon ready for testing

https://addons.mozilla.org/en-US/firefox/addon/tab-groups-panorama/

the code can be found here
https://github.com/Quicksaver/Tab-Groups

more details here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1222550#c42
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: