Closed Bug 1357214 Opened 7 years ago Closed 7 years ago

Tab Groups API

Categories

(WebExtensions :: Untriaged, enhancement)

Product:
WebExtensions
Component:
Untriaged
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 1384515

People

(Reporter: u462496, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Keywords: parity-chrome, Whiteboard: [design-decision-denied]) 

Per discussion in bug 1322057, which was closed in favor of moving into bug 1333837 meta bug.  Now it has been recommended to put this into its own bug.

To reiterate:

First of all please note that I am NOT asking for an implementation of Panorama.

The basics:

An API that would offer a grouping paradigm and assign tabs a group id and name.  Also a method of tracking which would designate the "active" group.  In concept this is a simple as |tab.groupId = 123| |tab.groupName = "apples"| |browser.tabs.activeGroupId = 456|.

A means to hide tabs in native UIs eg tabs bar which are not identified as being in the active group.  While this is not absolutely necessary (addons usually have their own UIs) it would be naturally expected by tab groups users to experience the tab groups representation through the native UI.

browser.tabs.queryGroups() / browser.tabs.updateGroups()
- renaming, listing groups in the groups paradigm;  adding, removing, reassigning tabs to a different group.  Maybe other conveniences as well.

Possibly expose groups data through browser.tabs.query().

The hiding of tabs in the native UI could be handled a couple of different ways:

1)  Directly within the tab groups API.
2)  As a separate API.

An API for this would be valuable in that addons interested in tab groups support would all be on the same page.  I have a tab groups addon in which some of my users also use another tab groups addon concurrently in order to benefit from the features offered in both.  A central API would help eliminate conflicts from addons doing their own implementations.  An API for this would also be necessary in order to allow the grouping paradigm to be expressed through the native UI.

The basic implementation of this seems it would be almost trivial.
There have been requests for the tab group API before primarily bug 1232178 and bug 1352989l So I guess the question is why shouldn't we mark as resolved duplicate to those.

"it would be naturally expected by tab groups users to experience the tab groups representation through the native UI", so I'm confused how we'd do that without "an implementation of Panorma"
(In reply to Andy McKay [:andym] from comment #1)
> There have been requests for the tab group API before primarily bug 1232178
> and bug 1352989l So I guess the question is why shouldn't we mark as
> resolved duplicate to those.
> 
> "it would be naturally expected by tab groups users to experience the tab
> groups representation through the native UI", so I'm confused how we'd do
> that without "an implementation of Panorma"

Maybe herein lies the difficulty of this.  Panorama was a huge implementation for the tab grouping paradigm which had its UI convoluted with its functionality.  If I may say this, IMO it was a nightmare.  The code was very convoluted and the UI was very resource intensive.

What I am suggesting here is what would simply set up a __paradigm__ of having tabs in groups, just as I described.  Tabs having properties as identifiers which would describe which "group" they belong to, and maybe a few methods to change those identifiers.   It seems so simple to me, and honestly, I just cannot understand the resistance that this concept has met.  I can only guess that when people hear the word "tab groups", they think "Panorama" and run away screaming.

What I am requesting would only be backend support, with POSSIBLY the additional option UI-wise to show/hide tabs in the tabs bar.  It would be up to addons to supply anything beyond that, and if someone wanted to, could even build a UI that mimics "Panorama".

I know this Tab Groups thing has been a long debate, but I hope all can see the simplicity and low cost of what I am asking for here.  Mega tab users have relied on the tab grouping paradigm to help manage an unruly number of tabs, even if not using the Panorama UI, but extensions that have used Panorama to define the groups, simply to remain harmonious to all other tab groups UI implementations.  There does not seem to be an insignificant number of users who would like to see some sort of tab grouping feature, based on discussions I have read, and also inquiries from my own users who are concerned that this will disappear.
(In reply to Andy McKay [:andym] from comment #1)
> "it would be naturally expected by tab groups users to experience the tab
> groups representation through the native UI", so I'm confused how we'd do
> that without "an implementation of Panorma"

Maybe what I didn't make clear was that the only UI representation I am talking about is simply hiding tabs not belonging to the "active" "group".  I am not talking about the Panorama UI with the graphical display of tabs, dragging dropping, etc.
I would ask
Whiteboard: [design-decision-needed]
I would ask that this at least be discussed in a triage meeting.
(In reply to Kevin Jones from comment #2)
> (In reply to Andy McKay [:andym] from comment #1)
> There does not seem to be an insignificant
> number of users who would like to see some sort of tab grouping feature,
> based on discussions I have read, and also inquiries from my own users who
> are concerned that this will disappear.

What can be done to help get some traction on this?
(In reply to Kevin Jones from comment #3)
> Maybe what I didn't make clear was that the only UI representation I am
> talking about is simply hiding tabs not belonging to the "active" "group". 
> I am not talking about the Panorama UI with the graphical display of tabs,
> dragging dropping, etc.

So we'd need support from the Firefox UI team on that. And you probably don't even need that. What you need is the ability to "hide" a tab and "restore" a tab from the tab strip. The WebExtensions code can be responsible for figuring out what to show and hide and when. But I strongly believe if there's any code to do that, then you also need code in Firefox to list all the hidden tabs - we should avoid APIs that leave users in an incomplete state.

Personally I think we should aim for bug 1332447 and then we don't have to ask for any support in the Firefox UI at all.
Flags: needinfo?(gijskruitbosch+bugs)
Flags: needinfo?(gijskruitbosch+bugs)
tl;dr: If we're only looking at designing for Panorama-alike add-ons, then we're likely to end up right where we are today. If we're looking at designing an API for alternative paradigms for tabbed browsing, we should be explicit about that as a use-case, and design for it.

Many problems in Panorama stemmed from the fact that the design of that feature was fundamentally different from the user model of a tabbed browser. This resulted in a feature that was promising yet incomplete, unstable and not performant, and ultimately unfulfilling even to its most ardent supporters.

I'm skeptical that the ability to hide/show tabs will resolve the problems that arose in the implementation of Panorama.

Specifically, these major issues would not be addressed:

* Still no resolution of multi-window behavior. The design of Panorama is a fundamentally for a single-window application. Re-read the comments on the multi-window bug: The problem was unresolvable in a way that made any sense in a tabbed browsing world - the level of complexity in marrying these incompatible worlds continually increased. https://bugzilla.mozilla.org/show_bug.cgi?id=578512

* The cost of inactive tabs is going down with all of the changes y'all have been working on, which is fantastic. However, the tabbed browser design is designed and optimized for a user behaviour pattern where tabs *are* the current workspace. We can only work around that for so long before it bites us, as we found with Panorama. Once we allow "hiding" tabs, we may for a time enjoy add-ons which leverage the feature, but the ceiling for innovation there is low, and I expect we'll eventually see a newer class of bugs resulting from encouraging this architectural mismatch.

I prototyped an implementation of a "tab groups" concept which used the nsISessionStore APIs to save/restore the whole browser session when switching "groups", which mapped much better to the user model of Panorama. It resolved multi-window and also completely worked around the friction between tabbed browser architecture (all tabs are current workspace) and Panorama design (some tabs are current workspace) by encapsulating the entire tabbed browser architecture instead of trying to integrate with it. This is definitely not a way forward, but I'm mentioning it to illustrate how different the model needs to be in order to 1) be useful for creating innovative tabbed browsing alternatives and 2) avoid the multitude of problems that arose out of architectural frictions with tabbed browsing paradigm.

The full expression of the Panorama design would ultimately remove the need for "tabs" or "windows", allowing alternate design metaphors to manifest out of the innovation vector created by leaving "tabs" and "windows" behind. See the work the Browser.html group have been doing over the last few years, and this post: http://medium.com/@patrykadas/lossless-web-navigation-with-trails-9cd48c0abb56. This is an example of re-envisioning browsing without tabs or windows. Could we implement this with the proposed tab hide/show changes? Probably not without getting super hacky again.

I think Andy is correct in comment #7 that the way forward is to offer the ability to hide the tab strip entirely, instead of playing games with "real tabs vs fake tabs" like we've done for years. It wouldn't fully meet the needs of a tab-groups use-case, as you'd still need to open/close/restore pages somehow. But I think it's a step in the right direction.
(In reply to Andy McKay [:andym] from comment #7)
> (In reply to Kevin Jones from comment #3)
> > Maybe what I didn't make clear was that the only UI representation I am
> > talking about is simply hiding tabs not belonging to the "active" "group". 
> > I am not talking about the Panorama UI with the graphical display of tabs,
> > dragging dropping, etc.
> 
> So we'd need support from the Firefox UI team on that. And you probably
> don't even need that. What you need is the ability to "hide" a tab and
> "restore" a tab from the tab strip. The WebExtensions code can be
> responsible for figuring out what to show and hide and when.

There is already support for that - gBrowser.hideTab/showTab/showOnlyTheseTabs - https://dxr.mozilla.org/mozilla-central/source/browser/base/content/tabbrowser.xml#3256-3311.

> But I strongly
> believe if there's any code to do that, then you also need code in Firefox
> to list all the hidden tabs - we should avoid APIs that leave users in an
> incomplete state.

There is support for that also: `tab.hidden` property.

browser.tabs.query():

diff --git a/browser/components/extensions/ext-utils.js b/browser/components/extensions/ext-utils.js
--- a/browser/components/extensions/ext-utils.js
+++ b/browser/components/extensions/ext-utils.js
@@ -635,6 +635,7 @@ ExtensionTabManager.prototype = {
       highlighted: tab.selected,
       active: tab.selected,
       pinned: tab.pinned,
+      hidden: tab.hidden,
       status: TabManager.getStatus(tab),
       incognito: PrivateBrowsingUtils.isBrowserPrivate(browser),
       width: browser.frameLoader.lazyWidth || browser.clientWidth,
(In reply to Kevin Jones from comment #9)
> There is already support for that -
> gBrowser.hideTab/showTab/showOnlyTheseTabs -
> https://dxr.mozilla.org/mozilla-central/source/browser/base/content/
> tabbrowser.xml#3256-3311.
>
> There is support for that also: `tab.hidden` property.

But neither of these are exposed to users or tested, and they are either unused or only used by preloaded tabs right now - neither being any good for shipping something out to webextensions that we then (a) have to support forever and (b) might break without us noticing and (c) conflates internal things (like preloaded about:newtab browsers) with things add-ons want to do (like tab groups).

Basically, this stuff only barely survived me removing the rest of tab groups, mostly because it was tied into the preload stuff and I didn't want to break things. I suspect showOnlyTheseTabs should probably have died with tab groups, and I'll check and file a followup to remove it if I'm right and it's just dead code at this point.

I concur with Andy and Dietrich - we should allow add-ons to hide the tabstrip, and then they can do more or less what they like.
(In reply to :Gijs from comment #10)
> (In reply to Kevin Jones from comment #9)
> > There is already support for that -
> > gBrowser.hideTab/showTab/showOnlyTheseTabs -
> > https://dxr.mozilla.org/mozilla-central/source/browser/base/content/
> > tabbrowser.xml#3256-3311.
> >
> > There is support for that also: `tab.hidden` property.
> 
> But neither of these are exposed to users or tested, and they are either
> unused or only used by preloaded tabs right now - neither being any good for
> shipping something out to webextensions that we then (a) have to support
> forever and (b) might break without us noticing and (c) conflates internal
> things (like preloaded about:newtab browsers) with things add-ons want to do
> (like tab groups).

a) Isn't it that way with all of it?
b) ????
c) I can see your point there. 

> I concur with Andy and Dietrich - we should allow add-ons to hide the
> tabstrip, and then they can do more or less what they like.

As I stated in my proposal, show/hide tabs was not an absolute necessity, so I am not pressing this argument.  My main goal is to have a central API for the grouping paradigm so that addons aren't all doing there own thing, and thus be in conflict.

There seems to be a lot of conviction about not showing/hiding tabs from those who know a lot more about the full ramifications of this than me.  And while my argument may be "let the users choose which they prefer", I even may be seeing how having a mixed architecture could be a problem.

So I am happy to concede, and am grateful there will at least be the option to hide the tabs bar.
(In reply to Kevin Jones from comment #11)
> (In reply to :Gijs from comment #10)
> > (In reply to Kevin Jones from comment #9)
> > > There is already support for that -
> > > gBrowser.hideTab/showTab/showOnlyTheseTabs -
> > > https://dxr.mozilla.org/mozilla-central/source/browser/base/content/
> > > tabbrowser.xml#3256-3311.
> > >
> > > There is support for that also: `tab.hidden` property.
> > 
> > But neither of these are exposed to users or tested, and they are either
> > unused or only used by preloaded tabs right now - neither being any good for
> > shipping something out to webextensions that we then (a) have to support
> > forever and (b) might break without us noticing and (c) conflates internal
> > things (like preloaded about:newtab browsers) with things add-ons want to do
> > (like tab groups).
> 
> a) Isn't it that way with all of it?

Yes, but it's a significant downside when it comes to questionable APIs. I don't see us getting rid of creating/removing tabs any time soon. Hiding tabs... less sure. Once you lock into a particular API, that's it, now you can't change it because people rely on it working the way it does.

> b) ????

If there are no internal consumers for the API, it's hard to test that it works correctly. Testing something in the abstract works only to some degree - I've seen some of that working on the customizable UI code for toolbar/panel button management. Abstraction layers and unit tests (which we do seem to have for hidden tabs) look really nice until they hit the real world and all the crazy things add-ons do (as a tiny example that I only noticed 3 years after that code shipped, see e.g. bug 1341562).

In this case, the real world comes in the form of, sampling off the top of my head:
1) what to do when the last non-hidden tab closes / when the group is empty?
2) what to do when a hidden tab pops up a modal dialog?
3) what happens if the user tries to close a hidden group or tab that contains a tab that pops up an onbeforeunload ("Are you sure you want to leave...") dialog?
4) what happens when tabs opened by script that are the last tab in a group close themselves?
5) what happens when, say, you solve (3) by showing that tab, and some *other* tab reacts to the visibilitychanged event by firing up a modal dialog (2) *and* the user has given permission for that tab to steal focus? (Bonus: the dialog in that second tab won't work now, that's bug 727801).

etc. etc. And that's beside all the good points from Dietrich about the conflicts between groups and windows.

This is not an easy problem to solve, and the solutions depend to some degree on the paradigms the developer wants to pursue and how they do so (see, again, Dietrich's comment). Locking in those paradigms into a fixed APIs all add-ons then have to use is problematic. In a way, I personally feel it'd be much more sensible to just unload the tabs that get hidden (cf. bug 1322485), as that solves a bunch of the problems above, but you'd still have to get the UI right for that, and I'm sure some users wouldn't like that solution and would prefer some other fix. But it's hairy, and laying it all down in our own implementation seems like a bad idea.

If an interchange format between different add-ons is required, it is fully possible for those add-ons to develop one without our help (much like there are various web page archive formats, you can import/export citations from zotero in various formats, etc.). 

> c) I can see your point there. 
> 
> > I concur with Andy and Dietrich - we should allow add-ons to hide the
> > tabstrip, and then they can do more or less what they like.
> 
> As I stated in my proposal, show/hide tabs was not an absolute necessity, so
> I am not pressing this argument.  My main goal is to have a central API for
> the grouping paradigm so that addons aren't all doing there own thing, and
> thus be in conflict.

I don't see any real way we can avoid this conflict except by implementing 99% of the feature ourselves and forcing add-ons to move within those limitations, which I don't think is a good outcome considering there's still so much uncertainty about a Good Way to fix this problem. Edge now has a "set these tabs aside" feature that is vaguely like tab groups, there were UX designs for alternative versions beyond what we originally implemented, there are minimalist takes on the theme on AMO... there's still lots of exploration. That's besides the obvious maintenance burden and problems with ensuring quality.
Gjis: comment 12 - I see.  Thanks for the explanation.  I don't want to press my point (any more than I already have).  I am starting to see now why there has been so much opposition to tab groups, and that it doesn't just have to do with show/hide tabs.  Mozilla has gotten a lot of flack over the move away from the old "wild west" addon development platform as many fear things they have cherished are going to be lost.  But I believe that the move is good overall and a move to a more stable and better performing environment.
(In reply to Kevin Jones from comment #5)
> I would ask that this at least be discussed in a triage meeting.

I retract that and trust you guys to handle this whatever way you see is best.
Already my Bugzilla group have more as 30 tabs. Show me a way to work with 250 Tabs and please tell me not with bookmarks or 12 windows. By the way there are addons which use some of the above mentioned "unneeded" functions. If you want to remove these, then please not before Fx 57. 

From my point of view here will be to much discussed about this implemented "addon". Panorama was a nightmare in all directions. I have never used this. Panorama should be an example to make it better the next time and not an example why you do not want it. And we need no GUI for group management, we need an API to make things possible.

In the matter of fact we can not help ourself anymore and programing what we need. This should be considered in all results of discussions. Mozilla made the decisions with all wanted consequences and one of them is now, that Mozilla is in charge to make things possible. Mozilla wants to handle this alone and to have the full control, so please make the powerful API's.
I think hiding tabs is a must have here. If you're creating a simple add-on that just filters existing tabs by a search query, or by container or other things (like Tab Center), recreating a brand new tab bar just to hide a couple of tabs is not the way to go IMO.
(In reply to :Gijs from comment #12)
> (In reply to Kevin Jones from comment #11)
> > (In reply to :Gijs from comment #10)
> > > (In reply to Kevin Jones from comment #9)
> > > > There is already support for that -
> > > > gBrowser.hideTab/showTab/showOnlyTheseTabs -
> > > > https://dxr.mozilla.org/mozilla-central/source/browser/base/content/
> > > > tabbrowser.xml#3256-3311.
> > > >
> > > > There is support for that also: `tab.hidden` property.
> > > 
> > > But neither of these are exposed to users or tested, and they are either
> > > unused or only used by preloaded tabs right now - neither being any good for
> > > shipping something out to webextensions that we then (a) have to support
> > > forever and (b) might break without us noticing and (c) conflates internal
> > > things (like preloaded about:newtab browsers) with things add-ons want to do
> > > (like tab groups).
> > 
> > a) Isn't it that way with all of it?
> 
> Yes, but it's a significant downside when it comes to questionable APIs. I
> don't see us getting rid of creating/removing tabs any time soon. Hiding
> tabs... less sure. Once you lock into a particular API, that's it, now you
> can't change it because people rely on it working the way it does.
> 
> > b) ????
> 
> If there are no internal consumers for the API, it's hard to test that it
> works correctly. Testing something in the abstract works only to some degree
> - I've seen some of that working on the customizable UI code for
> toolbar/panel button management. Abstraction layers and unit tests (which we
> do seem to have for hidden tabs) look really nice until they hit the real
> world and all the crazy things add-ons do (as a tiny example that I only
> noticed 3 years after that code shipped, see e.g. bug 1341562).
> 
> In this case, the real world comes in the form of, sampling off the top of
> my head:
> 1) what to do when the last non-hidden tab closes / when the group is empty?
> 2) what to do when a hidden tab pops up a modal dialog?
> 3) what happens if the user tries to close a hidden group or tab that
> contains a tab that pops up an onbeforeunload ("Are you sure you want to
> leave...") dialog?
> 4) what happens when tabs opened by script that are the last tab in a group
> close themselves?
> 5) what happens when, say, you solve (3) by showing that tab, and some
> *other* tab reacts to the visibilitychanged event by firing up a modal
> dialog (2) *and* the user has given permission for that tab to steal focus?
> (Bonus: the dialog in that second tab won't work now, that's bug 727801).

I don't see how this is solved by hiding the tabbar and recreating a new one. If anything, people will think the UX is broken if a tab starts showing out of no where (without any corresponding tab) with the "Are you sure you want to leave ..." dialog.

In both case, this needs to be handled...
(In reply to Tim Nguyen :ntim from comment #17)
> I don't see how this is solved by hiding the tabbar and recreating a new
> one. If anything, people will think the UX is broken if a tab starts showing
> out of no where (without any corresponding tab) with the "Are you sure you
> want to leave ..." dialog.
> 
> In both case, this needs to be handled...

You snipped out my suggested solutions, which have different cost/benefit trade-offs, some of which may or may not appeal to users. An add-on could decide to unload all the tabs in a group that gets hidden, for instance, which makes some of these issues go away, removing the need for this to be handled by UI (Firefox's or the add-on's).

But even without that, if the add-on reimplements the tab bar, it's up to the add-on on how they surface the tab in question, right? They will get tab selection events (onActiveChanged) the same way they do now, and can handle them appropriately if the add-on thinks the tab is in a hidden group (e.g. swap out hidden/visible groups in its own UI).


(In reply to Tim Nguyen :ntim from comment #16)
> I think hiding tabs is a must have here. If you're creating a simple add-on
> that just filters existing tabs by a search query, or by container or other
> things (like Tab Center), recreating a brand new tab bar just to hide a
> couple of tabs is not the way to go IMO.

Why not? Rather than hiding specific tabs, or reimplementing the tab bar, it would be pretty easy to just present the matching tabs in separate UI (like a popup, sidebar, in-content page... whatever), and allow switching to tabs from there. That would also make it easier to:
- show results from multiple windows in one view
- show how a particular search query matched a tab (by highlighting the relevant bits of the title or URL or whatever)
- display whatever additional information was used to filter the tabs (e.g. last time it was the selected tab), in ways that aren't possible with the stock tabstrip.

etc.

Unless we give add-ons full-on XUL access to the stock tab strip, there will always be aspects of the tab appearance that they would like to customize under specific circumstances, but can't (directly). Rather than providing for all of those direct manipulations and their permutations via custom APIs, it seems much simpler to leave add-ons to address that problem the way they think makes the most sense, and offer them the option of hiding the tabstrip.
Hiding the tab strip as per bug 1332447 is the preferred solution for a few (but not all people) on this bug. It gives add-on authors the ability to replace the tab strip without having to ask for permission. Hopefully this also provides more context to the other tab group bugs like: bug 1232178, bug 1352989 and so on.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Whiteboard: [design-decision-needed] → [design-decision-denied]
> Why not? Rather than hiding specific tabs, or reimplementing the tab bar, it
> would be pretty easy to just present the matching tabs in separate UI (like
> a popup, sidebar, in-content page... whatever), and allow switching to tabs
> from there. That would also make it easier to:

No.  No.  No.  No.  No.  No.  No.  No.

The whole point of tab management extensions is to allow users to change how they use TABS.  Not use something else.  Tabs.
I have kind of lost track of all the discussion of this which crosses several bugs.  I am re-opening this bug based on the following argument:

My original proposal was two-fold:

1) Supply an API which provides a tab grouping paradigm.

2) Show/Hide tabs in the tabs bar based on group designation.

It seems what happened with this bug is that the decision was eventually made to not hide tabs, but to allow hiding the tabstrip and allow addon devs to provide their own UI.  (Now it appears even that option may be getting/have gotten axed.)

There has been so much discussion over tab groups across several bugs and I may have gotten confused, but if I understand correctly, this bug was marked as WONTFIX based on the fact that we would not be hiding tabs.

However, this ignored a significant component of this bug.  That is an API which would provide a tab grouping paradigm.  (Please see the first part of the "the basics" in the OP.)  As one can see from the proposal, this would be a fairly trivial API.

I am stressing here, I am in no way arguing for any UI support for tab groups.  I am only arguing the need for a native API which would define tab groups.  My arguments are as follows:

First of all, without a way to assign tabs a certain designation, there will be no way to persist groups after shutdown.

With that said, it may be possible for devs to create their own grouping paradigm and persist it using bug 1322060.  (Note that the data stored using this API is privy only to the addon which stored it.)

__However__, each addon would have their own thing going on.

The reason I feel a central API is so important is so authors who wish to create a UI for tab groups would all be in harmony.  Users could use more than one tab groups addon which each offer different UI options (and some did), each of which offer features that are useful in different situations.  Also, if a user chooses to stop using one tab groups addon in favor of another, their groups would still be there and they don't have to figure out a way to migrate and start all over.

So again I am stressing, I am very happy to let go of any UI support here.  It is only a common backend I am requesting, one of which AFAICT would be quite trivial.

Please consider this.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
1) Containers already provides tab colouring despite being about security you could break that paradigm.
Also titles and tab content could be changed colour or a page action to indicate the group.

2) This was already discussed and is being worked on / has been approved. By reimplementing tabs: Bug 1332447 or hiding tabs Bug 1384515
Status: REOPENED → RESOLVED
Closed: 7 years ago → 7 years ago
Resolution: --- → DUPLICATE
(In reply to Jonathan Kingston [:jkt] from comment #24)
> 1) Containers already provides tab colouring despite being about security
> you could break that paradigm.
> Also titles and tab content could be changed colour or a page action to
> indicate the group.
> 
> 2) This was already discussed and is being worked on / has been approved. By
> reimplementing tabs: Bug 1332447 or hiding tabs Bug 1384515

I'm sorry, I just don't get it.  I feel like you don't understand what I am asking here.  The bugs you mentioned all have to do with UI.  I am NOT talking about UI!!!

I am talking about a means of an addon being able to get/set a property on each tab that is globally accessible to other addons, and that will persist across restarts.  Just an identifier to which group it belongs.  Firefox would not be doing anything with those groups, not changing UI, it would be up to the addon to use this data to provide any UI it wants to express this, using bug 1332447, bug 1384515 or however it chooses.  This data would be accessible to all addons so that all tab grouping addons would be on the same page, as I described in comment 23.  That is ALL.  Nothing more.  What is the security issue in that?

This would be completely independent of bug 1332447 and bug 1384515.

Containers is in no way close to a substitute for tab groups.

Andy, could you please comment on this?  And please see also comment 23.
Flags: needinfo?(amckay)
You have both opener and containers as a unique id for the tab, I'm not sure why you need something else?
See Also: → 1232178
(In reply to Jonathan Kingston [:jkt] from comment #26)
> You have both opener and containers as a unique id for the tab, I'm not sure
> why you need something else?

Jonathan, I'm not familiar with what you are talking about here.  Are these properties of some kind?  I don't find any corresponding properties of tabs.Tab.  I see `openerTabId`, but that is only the tabId of the opener tab, and tabId's don't persist across restarts.

Can you give an brief example of how I would use what you say here to obtain a unique id for a tab, which will persist after shutting down then restarting the browser?
(In reply to Dietrich Ayala (:dietrich) from comment #8)
> tl;dr: If we're only looking at designing for Panorama-alike add-ons, then
> we're likely to end up right where we are today. If we're looking at
> designing an API for alternative paradigms for tabbed browsing, we should be
> explicit about that as a use-case, and design for it.
> 
> Many problems in Panorama stemmed from the fact that the design of that
> feature was fundamentally different from the user model of a tabbed browser.
> This resulted in a feature that was promising yet incomplete, unstable and
> not performant, and ultimately unfulfilling even to its most ardent
> supporters.
> 
> I'm skeptical that the ability to hide/show tabs will resolve the problems
> that arose in the implementation of Panorama.


Dietrich, first I'd like to thank you for your excellent analysis here. You've identified several issues that are of concern for the future development of Firefox.

I'd like to point out a novel approach to Tab Groups that many developers aren't aware of, but that thousands of users have found ABSOLUTELY CRITICAL to their workflow. I recognize that this thread is mostly about the technical integration required for something Tab-Groups-like, but I'd like to share a concept/paradigm with you.

Have you ever seen TabGroups Manager?

https://addons.mozilla.org/en-US/firefox/addon/tabgroups-manager-revived

When most browser users want Tab Groups, what they are really looking for is just an easy way to quickly group the tabs they have open into useable categories. Those users defaulted to Panorama-based groups in Firefox (terrible implementation as it was) because there were no other real options than Panorama, since that's what Mozilla chose to implement. But users like me found it frustrating to have to jump back and forth between a secondary, abstracted environment (Panorama) and the normal Firefox user environment anyway. We just wanted easy tab grouping. So your points are well-taken.

The problem is, users like me still need some way to group tabs. I have several "workspaces" running at once, and I need to quickly be able to jump between sets of tabs grouped logically. So how does TabGroups Manager help me do that?

(1) The most important feature: The add-on creates one level of hierarchy (Tab Groups) which are represented as an extra bar in the tab area. (Please see the screenshots on the add-on page.) This allows the user to organize Tab Groups directly in the main browser window view, without having to flip to a secondary "Panorama" screen. The user can create hierarchy, name the groups, and manage tabs (drag-and-drop between tab groups) in a quick, convenient way that provides visual context at all times.
(2) Secondary feature: The add-on allows the user to hibernate tab groups to improve performance.

This is an incredible workflow booster. Please check it out and review it in light of your thoughts about the way forward. Of course, the add-on will no longer work in Firefox 57+. To me, it doesn't make sense to be forced to have tabs completely disorganized, which is the current new paradigm in Firefox.
Flags: needinfo?(kevinhowjones)
Flags: needinfo?(kevinhowjones)
Flags: needinfo?(amckay)
Can we please get this moved out of duplicate status? The discussion here has clearly moved beyond toggling visibility of tabs.
Product: Toolkit → WebExtensions
(In reply to benshadwick from comment #29)

> Can we please get this moved out of duplicate status? The discussion here
> has clearly moved beyond toggling visibility of tabs.

+1

(In reply to u462496 from comment #0)

> … The basics:
> 
> An API that would offer a grouping paradigm and assign tabs a group id and
> name.  Also …
> 
> …

> An API for this would be valuable in that addons interested in tab groups
> support would all be on the same page.  I have a tab groups addon in which
> some of my users also use another tab groups addon concurrently in order to
> benefit from the features offered in both.  A central API would help
> eliminate conflicts from addons doing their own implementations. …

As predicted, we have diverse implementations and conflicts. 

I don't recall seeing this bug before 1357214 today. If I had seen it, I would have approached these things differently: 

API for groups (for tab groups) - Add-ons - Mozilla Discourse
<https://discourse.mozilla.org/t/-/28533?u=grahamperrin>

– the outcome of which was: 

Interop: a common approach to defining tab groups, tab group members etc. for extensions for Firefox · Issue #73 · photodiode/panorama-view
<https://github.com/photodiode/panorama-view/issues/73>
Blocks: 1232178
Depends on: 1410548
Blocks: 1333837
See Also: → 1512802
See Also: → mult_sessions2

I would like this to happen at some point. It would be really useful for tab management across add-ons.
Just to add something to the conversation, here is a little API proposal.

New tab groups API, similar to that of windows and tabs

browser.tabGroups.create({title, windowId});
browser.tabGroups.remove(groupIds);
browser.tabGroups.move(groupIds, windowId);
browser.tabGroups.query({active, currentWindow, windowId, title});
browser.tabGroups.update(groupId, {active, title});

Additions to sessions API

browser.sessions.setTabGroupValue(groupId, key, value); // can be used for adding custom values, like visual size in panorama, etc..
browser.sessions.getTabGroupValue(groupId, key);
browser.sessions.removeTabGroupValue(groupId, key);

Additions to the tabs API "query" and "move" options

browser.tabs.query({tabGroupId: id});
browser.tabs.move(tabIds, {tabGroupId: id});

I don't know if this suggestion is helpful, but I hope it is.

See Also: → mult_sessions1
See Also: → mult_sessions_API
See Also: mult_sessions2, mult_sessions1 →
See Also: → 1509350

I have a suggestion, how if collections were treated as groups? And maybe make API compatible with chrome grouping API? https://developer.chrome.com/docs/extensions/reference/tabs/#method-group

(In reply to kroppy from comment #32)

Nice find, kroppy. Thank you.

Firefox parity with the tabs.group method of the chrome.tabs API in Google Chrome

The reporter of this bug can not be found at the originally given e-mail address so please, can someone else add the relevant keyword?

parity-chrome

– then https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard=%20%5Bdesign-decision-denied%5D%20&status_whiteboard_type=substring&keywords=parity-chrome&order=Importance&product=WebExtensions&keywords_type=allwords&classification=Components&query_format=advanced might help to show that tab groups has become the only WebExtensions area where parity with Chrome is denied (or words to that effect).

Thank you.

Given that Google recognises people's use cases for tab groups, we shouldn't need to repeat (or expand upon) our individual use cases, but here's another:

Flags: needinfo?(mixedpuppy)

Chromes tab group api, released a short while ago, is built on top of a browser feature. It would probably be better to pursue a polyfill api at this time.

Flags: needinfo?(mixedpuppy)

I have been playing with making a polyfill API for tab grouping in my add-on and would like to share it here.
https://gist.github.com/photodiode/7949475b76ad7d5ea0c8063772d1759f

This API is mostly based on the one from chrome, but with the addition of tabGroups.create() and tabGroups.remove() to try and be more friendly to different use cases. tabs.group() and tabs.ungroup() are also removed in favor of doing it through tabs.update().

If tab groups won't be implemented as a standard Firefox feature then at least I hope we can create an official add-on providing this functionality.

You need to log in before you can comment on or make changes to this bug.