In attempt to support Tab Groups Helper (NOT Panorama) and All Tabs Helper addons, I am needing to be able to read `hidden` property of tabs.

(In reply to Kevin Jones from comment #1) > Created attachment 8816793 [details] [diff] [review] > Patch to reference `tab.hidden` property in tabs.Tab If anyone could advise me who I should ask for review, much appreciated.

(In reply to Kevin Jones from comment #2) > (In reply to Kevin Jones from comment #1) > > Created attachment 8816793 [details] [diff] [review] > > Patch to reference `tab.hidden` property in tabs.Tab > > If anyone could advise me who I should ask for review, much appreciated. Thanks for looking into this, Kris Maglione is for sure the best reviewer for the tabs API. In the current form, this patch can be considered ready for a feedback request (that can be very helpful, e.g. to know if it is something that we can solve using this strategy or if we need to evaluate different strategies), while for a review request is usually better to have already included a test case for it (e.g. by looking at the existent tests for the tabs API and then creating a new test case and/or test assertion for the hidden tabs scenario).

I'm hesitant to implement this attribute. If we're going to give extensions access to tab grouping, I'd rather we actually implement a tab grouping API. I'll bring this up at the next advisory group meeting.

A tab grouping API would be ideal. A native API would be better than tab group addons each trying to implement their own API, thus making them incompatible. Would what you are talking about just be a backend, where addons could implement their own UIs? Or would this native API include a UI also? If so, I certainly hope this would be something much different than the old Panorama API which is extremely inefficient and also carries the overhead of a fairly expensive UI.

A bare bones backend would not have to be much more than the ability to hide tabs, a way of creating group identifications, and a way of identifying tabs as belonging to a certain group, all which would be stored as session data. This alone AFAICT would be enough for addons to implement the other usual tab group actions and whatever UI they want to present to the user. A little more robust backend could include APIs to delete groups (and the tabs they contain), move tabs between groups, get all tabs in a group, etc.

It will likely just be an API. It will be up to add-ons to provide any UI for it. Panorama never had an API. Some add-ons reached into its UI code and tried to pretend that it was an API, but it wasn't.

Comment on attachment 8816793 [details] [diff] [review] Patch to reference `tab.hidden` property in tabs.Tab Review of attachment 8816793 [details] [diff] [review]: ----------------------------------------------------------------- Canceling feedback until we've discussed this in the advisory board.

(In reply to Kris Maglione [:kmag] from comment #7) > Panorama never had an API. Some add-ons reached into its UI code and tried > to pretend that it was an API, but it wasn't. That's a good way of putting it. Unfortunately at the time, it was the only native *something* that addons could rally around so as to avoid conflicts.

(In reply to Kevin Jones from comment #9) > (In reply to Kris Maglione [:kmag] from comment #7) > > Panorama never had an API. Some add-ons reached into its UI code and tried > > to pretend that it was an API, but it wasn't. > > That's a good way of putting it. Unfortunately at the time, it was the only > native *something* that addons could rally around so as to avoid conflicts. Agree. But I think we can do better this time.

Another pretty essential feature for the API would be messages for group created/removed, tab added/removed to/from group, etc.

Instead of adding a custom property for something that's not supported by Firefox internals, what about adding a way for WebExtensions to attach pieces of data to a tab? So TabGroups could add a "groupId", SnoozeTabs could add a "wakeupTime", TabCenter could add a "thumbnail", etc… To be clear, this is just an idea that popped into my head. I haven't thought out the design or the ramifications yet.

(In reply to Blake Winton (:bwinton) (:☕️) from comment #12) > Instead of adding a custom property for something that's not supported by > Firefox internals, what about adding a way for WebExtensions to attach > pieces of data to a tab? So TabGroups could add a "groupId", SnoozeTabs > could add a "wakeupTime", TabCenter could add a "thumbnail", etc… > > To be clear, this is just an idea that popped into my head. I haven't > thought out the design or the ramifications yet. Actually, tab.hidden is a property within the XUL tabbrowser API. My initial request is just to expose that property in the browser.tabs API. However, I am much encouraged by the proposal for a bonafide Tab Groups API which for my purposes is a much more desirable solution. Nevertheless, +1 for the convenience of adding custom properties to tabs. While an extension could always hold the custom properties in a hash of `tab.id`s for its own internal use, properties attached using the tabs API would be globally accessible, and extensions could operate cooperatively (Though sometimes I get the feeling though that global communication is not exactly the direction WE wishes to go). Feel free to file a bug.

tab.hidden definitely is (and I agree should be added). tab.group, or messages when tabs are added/removed from groups, on the other hand, I feel would be better expressed as custom data. I don't have any plans to use the custom data, so I'm probably not going to file the bug, but now the idea is out there, and maybe kmag or andym will remember it at an opportune point in the future. ;) Thanks for letting me ramble!

The ability to store metadata on a tab sounds like bug 1280222. As per bug 1280222 comment 1, if that was to happen there should be a decent amount of isolation so add-ons don't collide with each other.

(In reply to Kris Maglione [:kmag] from comment #4) > I'm hesitant to implement this attribute. If we're going to give extensions > access to tab grouping, I'd rather we actually implement a tab grouping API. > > I'll bring this up at the next advisory group meeting. Kris, how did it come out, is there any news on this?

(In reply to Kevin Jones from comment #16) > Kris, how did it come out, is there any news on this? The next advisory group meeting isn't until next month. I'll keep you updated.

(In reply to Blake Winton (:bwinton) (:☕️) from comment #12) > Instead of adding a custom property for something that's not supported by > Firefox internals, what about adding a way for WebExtensions to attach > pieces of data to a tab? So TabGroups could add a "groupId", SnoozeTabs > could add a "wakeupTime", TabCenter could add a "thumbnail", etc… > > To be clear, this is just an idea that popped into my head. I haven't > thought out the design or the ramifications yet. I'd definitely like to have an API to add session store data to tabs, but that would probably only be accessible to the extension that added it, and is a separate bug.

(In reply to Kris Maglione [:kmag] from comment #4) > I'm hesitant to implement this attribute. If we're going to give extensions > access to tab grouping, I'd rather we actually implement a tab grouping API. > > I'll bring this up at the next advisory group meeting. Kris, is anything happening regarding a tab grouping API? It would be good to know what direction I need to move on this. Presently I am on hold regarding migrating my Tab Groups addon (Tab Groups Helper) and would like to be able to have time to prepare before the XUL version is defunct.

I really think supporting tab.hidden is safe enough and is compatible with the purpose of WebExtensions. Can we do that ? That provides more flexibility than a tab grouping API in my opinion.

It's going to have to be discussed by the advisory group. The next meeting is next Wednesday. I'll update the bug after the discussion.

(In reply to Kris Maglione [:kmag] from comment #22) > It's going to have to be discussed by the advisory group. The next meeting > is next Wednesday. I'll update the bug after the discussion. Thanks kindly, Kris. I don't think bug 1332377 alone is sufficient for this if we want to support Tab Groups addons, otherwise we could get end up with conflicting addons as authors try to implement their own version of a Tab Groups API. At least the bare bones option that I mentioned in comment 6 would (I believe) be enough to keep everyone on the same track. A more robust version would be nice though.

(In reply to Kevin Jones from comment #23) > (In reply to Kris Maglione [:kmag] from comment #22) > > It's going to have to be discussed by the advisory group. The next meeting > > is next Wednesday. I'll update the bug after the discussion. > > Thanks kindly, Kris. I don't think bug 1332377 alone is sufficient for this > if we want to support Tab Groups addons, otherwise we could get end up with > conflicting addons as authors try to implement their own version of a Tab > Groups API. At least the bare bones option that I mentioned in comment 6 > would (I believe) be enough to keep everyone on the same track. A more > robust version would be nice though. If we handle precedence correctly like we do for other pref overrides, I don't think this should be an issue. I think hiding tabs is much more flexible that being able to group tabs. I mean if an add-on wanted to group tabs now, it could just query all tabs an maintain its own arrays of tabs, the only functionality that's missing would be hiding them. An API to group tabs doesn't prevent conflicts either, if an add-on uses groups like Tab Groups does, and another add-on uses groups to provide a search-box for tabs (by creating a filtered-out group and a filtered-in group), both add-ons will conflict as well.

(In reply to Tim Nguyen :ntim from comment #24) > (In reply to Kevin Jones from comment #23) > > If we handle precedence correctly like we do for other pref overrides, I > don't think this should be an issue. I think hiding tabs is much more > flexible that being able to group tabs. I mean if an add-on wanted to group > tabs now, it could just query all tabs an maintain its own arrays of tabs, > the only functionality that's missing would be hiding them. > > An API to group tabs doesn't prevent conflicts either, if an add-on uses > groups like Tab Groups does, and another add-on uses groups to provide a > search-box for tabs (by creating a filtered-out group and a filtered-in > group), both add-ons will conflict as well. Tim if I understand you correctly, it sounds like you are saying that there is no benefit in having anything more than an API which will hide tabs. I do not agree with this. If we have a native API that assigns tabs to a given group by creating an object (eg array) that provides references to the tabs assigned to that group, assigns a unique group ID and gives each tab a reference to that unique ID, and gives the user the opportunity to name those group definitions, if all Tab Group addons are using the native API for the group definitions and only providing the UI, we have continuity. We have one almighty definition of the tab groups. One could have two different "Tab Group" addons both of which might have some aspects of their UI which appeal to the same user. Say groups are created by using addon #1 UI, then later the user uses addon #2 to display a graphical layout of the groups, it would display something that is in harmony with the groups created by addon #1, because there is only a single defining API of what the groups are. It wouldn't matter which addon's UI was used to create the groups, the other addon's UI could always access the same groups. If groups were created with addon #1, then tabs were moved between groups with addon #2, when switching back to addon #1, the changes in the groups would be reflected. If however we leave it up to individual addons to maintain its own array of tabs, each one defining groups in whatever manner it chooses, if a user attempts to use two different "Tab Group" addons, there will be conflicts. Suppose the user creates groups with addon #1, then wants to display the groups in a certain manner only provided by addon #2, addon #2 has no concept of the group definitions created by addon #1. addon #2 would not be able to view the groups created with addon #1. Each would be creating it's own independent group definitions. In your example of the searchbox, I assume you are talking about a scenario where addon #1 creates groups using the API, then addon #2 filters tabs by hiding them based on say, tab titles matching a string. Yes, there could be a conflict here if addon #2 does not respect group assignments when showing/hiding tabs. But there will always be ways addons can conflict, and I don't believe this makes an argument that there is no benefit in having a single almighty API responsible for defining and naming groups.

(In reply to Kevin Jones from comment #25) > (In reply to Tim Nguyen :ntim from comment #24) > > (In reply to Kevin Jones from comment #23) > > > > If we handle precedence correctly like we do for other pref overrides, I > > don't think this should be an issue. I think hiding tabs is much more > > flexible that being able to group tabs. I mean if an add-on wanted to group > > tabs now, it could just query all tabs an maintain its own arrays of tabs, > > the only functionality that's missing would be hiding them. > > > > An API to group tabs doesn't prevent conflicts either, if an add-on uses > > groups like Tab Groups does, and another add-on uses groups to provide a > > search-box for tabs (by creating a filtered-out group and a filtered-in > > group), both add-ons will conflict as well. > > Tim if I understand you correctly, it sounds like you are saying that there > is no benefit in having anything more than an API which will hide tabs. I > do not agree with this. > > If we have a native API that assigns tabs to a given group by creating an > object (eg array) that provides references to the tabs assigned to that > group, assigns a unique group ID and gives each tab a reference to that > unique ID, and gives the user the opportunity to name those group > definitions, if all Tab Group addons are using the native API for the group > definitions and only providing the UI, we have continuity. We have one > almighty definition of the tab groups. One could have two different "Tab > Group" addons both of which might have some aspects of their UI which appeal > to the same user. Say groups are created by using addon #1 UI, then later > the user uses addon #2 to display a graphical layout of the groups, it would > display something that is in harmony with the groups created by addon #1, > because there is only a single defining API of what the groups are. It > wouldn't matter which addon's UI was used to create the groups, the other > addon's UI could always access the same groups. If groups were created with > addon #1, then tabs were moved between groups with addon #2, when switching > back to addon #1, the changes in the groups would be reflected. > > If however we leave it up to individual addons to maintain its own array of > tabs, each one defining groups in whatever manner it chooses, if a user > attempts to use two different "Tab Group" addons, there will be conflicts. > Suppose the user creates groups with addon #1, then wants to display the > groups in a certain manner only provided by addon #2, addon #2 has no > concept of the group definitions created by addon #1. addon #2 would not be > able to view the groups created with addon #1. Each would be creating it's > own independent group definitions. I see your point, but then it seems like a job for the chrome.runtime API here. The standard way for an chrome extension to expose an API is using chrome.runtime. Addon #1 could create groups, then any other addon could send a message to addon #1 to request the groups, and addon #1 could reply with the groups. Here's the relevant function: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/runtime/sendMessage I think it's rather unusual to have an API that doesn't have any UI. I'd rather have any add-on dependencies be explicit using the runtime API rather than having implicit dependencies (i.e. the addon #2 that would require the existence of groups created by the group API). That's a really uncommon API pattern within the WebExtension API. I'm not sure whether you're requesting the group API in addition to the hidden API, or instead of the hidden API; but if I had to choose 1 API, I'd rather support tab.hidden because it's much more flexible than having a grouping API. Anyway, I'm not the one making the decision here, just giving my opinion as add-on dev. I'll let the WE team make the call :)

Honestly, I do have trouble visualizing how your grouping API (the functions names, integration with the existing APIs, ...), but I'd love to see any proposal you can come up with, and I may be able to give a more informed opinion :)

(In reply to Tim Nguyen :ntim from comment #26) Hello Tim, somehow I don't think I'm communicating the concept very well. I don't know if you ever used Panorama (or the "Tab Groups" addon by Quicksaver/Luis Miguel which provided a shim when Panoram was removed) but the *concept* of "Tab Groups" originates there. Let me say up front I am not proposing duplicating anything much like Panorama, just giving an idea of how the concept appeared to the user. As Kris pointed out in comment 7, "Panorama never had an API. Some add-ons reached into its UI code and tried to pretend that it was an API, but it wasn't." Luis carried on Panorama in the form of the "Tab Groups" addon so to not disappoint many users who relied on it, or addons (such as my "Tab Groups Helper") which were dependent on it. I have been grateful for Luis's work as it kept TGH and others afloat, however Panorama has always been, IMO, if I may say this, kind of a mess. WebExtensions now gives us the opportunity to (or forces us to) come up with something better. So now, putting Panorama aside, the generic concept of Tab Groups is this: A user can assign certain tabs to "groups", which they can name. The user then is able to "select" that group, and only the tabs within that group are visible, either/or in the tabs bar, or an addon's custom UI. Say a user has 300 tabs for various browsing activities. He has 50 tabs that are related to doing searches for work on Mozilla addons, 50 tabs related to a search for a wifi component he wants to buy, 50 tabs of Youtube videos he watches for entertainment, etc, etc. He can create groups and name them "Mozilla", "wifi", "Youtube", etc. and assign the respective tabs to those groups. So whichever is the active "group", the user can work just with those tabs, without the clutter of all the others. The user can move tabs from one group to another. When he deletes a tab, it is removed from that group. If a tab is opened it is firstly assigned to the active group. Currently "Tab Groups" addon has over 109,000 users, so this is a concept that does not appeal to just a fringe user base. My proposal is that we provide a native API that at minimal, only provides the structure needed to define the groups and gives them names: 1) An object (eg array) which contains references to all the tabs contained within that group 2) A reference assigned to each tab (eg a group ID) which identifies that tab as belonging to that group // window: TabGroups = { groups: [ {groupID: "id_3", label: "Mozilla", tabs: [...]}, {groupID: "id_4", label:"wifi", tabs: [...]}, {groupID: "id_5", label:"youtube", tabs: [...]} ], activegroup: "id_4" } tab.groupID = "id_3", etc (NOTE: the `tabs: [...]` property in the group objects actually could be omitted since that relationship can be extracted from `tab.groupID` for each tab, though it would provide a great convenience) These definitions would be stored as SessionStore data, looking something like: "windows":[{...,"tabgroups":{"groups":[{"groupID":"id_3","label":"Mozilla"},{"groupID":"id_4","label":"wifi"},{"groupID":"id_5","label":"youtube"}],"activegroup":"id_4"},...},...] "tabs":[{...,"tabgroupID":"id_3",...},{...,"tabgroupID":"id_3",...},{...,"tabgroupID":"id_4",...},...] So manipulation of groups would look something like: If a tab is added, it is assigned to a group (probably the active one) If a tab is removed, the reference to that tab is removed from the group's object. If a tab is moved to a different group, the reference to that tab from the group's object to the new group's object > I think it's rather unusual to have an API that doesn't have any UI. I'd > rather have any add-on dependencies be explicit using the runtime API rather > than having implicit dependencies (i.e. the addon #2 that would require the > existence of groups created by the group API). That's a really uncommon API > pattern within the WebExtension API. I am not in favor of providing a native UI. What I am requesting is a simple native API so that Tab Group addons can rally around the same group definitions and avoid conflict. It would be up to the addons to provide the UI. Currently there are some very different UIs for Tab Groups each having an appeal for different users. I don't think Firefox should be burdened with a native UI for this, as it may just be dead weight for users who wish to use a different UI, and one more thing for Mozilla to maintain. I believe there is no concern that the API would end up without a UI. Myself and others, whom I am fairly certain would include Luis, would be ready to provide an interface. I agree it is an unusual practice, however I feel in the scenario I have lined out it would actually be less burdensome on Firefox development. However I concede that there may be ramifications of this of which I am unaware. Basically what my proposal is trying to accomplish is: Keep the current Tab Groups addons afloat by providing a means of grouping tabs Go one step further by providing a native API which will not just hide tabs, but define the groups so that all Tab Groups addons will be in harmony. > I see your point, but then it seems like a job for the chrome.runtime API > here. The standard way for an chrome extension to expose an API is using > chrome.runtime. Addon #1 could create groups, then any other addon could > send a message to addon #1 to request the groups, and addon #1 could reply > with the groups. The suggestion that chrome.runtime is the answer only means that it would be up to one addon to provide the API, and (if harmony is to be maintained) all other addons would need to rally around it. Also, the addon providing the API would need to receive messages from other addons to manage groups based on other addons' requests. There is the potential breakage for dependent addons anytime the host addon changes its API. All in all this to me is a fragile condition. I believe that a native API would finally provide a cohesiveness for a concept that has long been lacking in that. > I'm not sure whether you're requesting the group API in addition to the > hidden API, or instead of the hidden API; but if I had to choose 1 API, I'd > rather support tab.hidden because it's much more flexible than having a > grouping API. I am requesting the Tab Groups API, however in lieu of that, at least the hidden API. Nevertheless, AFAIC they could be concurrent, as there may be other addons who would wish to hide additional tabs in a group eg, the example you mentioned where an addon would hide tabs based on a search, or a myriad of other reasons. So I am requesting *at least* a `hidden` API, but would prefer a Tab Groups API. [1]Additional methods could be added to the native grouping API for convenience, eg, naming groups, adding tabs to a group, moving tabs to a group, deleting tabs from a group, etc.

needinfo-ing Kris bringing attention to the discussion beginning at comment 25.

(In reply to Kevin Jones from comment #28) > (In reply to Tim Nguyen :ntim from comment #26) > Hello Tim, somehow I don't think I'm communicating the concept very well. > > I don't know if you ever used Panorama (or the "Tab Groups" addon by > Quicksaver/Luis Miguel which provided a shim when Panoram was removed) but > the *concept* of "Tab Groups" originates there. Yes, I've used Tab Groups before. I've contributed to the add-on as well, but thanks for taking the time to introduce me to the add-on. > My proposal is that we provide a native API that at minimal, only provides > the structure needed to define the groups and gives them names: > > 1) An object (eg array) which contains references to all the tabs contained > within that group > 2) A reference assigned to each tab (eg a group ID) which identifies that > tab as belonging to that group > > // window: > TabGroups = { > groups: [ > {groupID: "id_3", label: "Mozilla", tabs: [...]}, > {groupID: "id_4", label:"wifi", tabs: [...]}, > {groupID: "id_5", label:"youtube", tabs: [...]} > ], > activegroup: "id_4" > } > > tab.groupID = "id_3", etc > > (NOTE: the `tabs: [...]` property in the group objects actually could be > omitted since that relationship can be extracted from `tab.groupID` for each > tab, though it would provide a great convenience) > > These definitions would be stored as SessionStore data, looking something > like: > > "windows":[{...,"tabgroups":{"groups":[{"groupID":"id_3","label":"Mozilla"}, > {"groupID":"id_4","label":"wifi"},{"groupID":"id_5","label":"youtube"}], > "activegroup":"id_4"},...},...] > "tabs":[{...,"tabgroupID":"id_3",...},{...,"tabgroupID":"id_3",...},{..., > "tabgroupID":"id_4",...},...] > > So manipulation of groups would look something like: > > If a tab is added, it is assigned to a group (probably the active one) > If a tab is removed, the reference to that tab is removed from the group's > object. > If a tab is moved to a different group, the reference to that tab from the > group's object to the new group's object The main question I have is: Should the tab bar UI only display the active group like the current tab groups add-on ? If yes, that's my main concern. I think the suggested API is too specific to the current Tab Groups add-on. Especially if this API replaces the hidden API. There are tons of ways to do tab groups, you could group them as a tree, you could group them as a stack (like Opera 12). And the suggested API doesn't really work for these use-cases. There are also tons of use-cases to hiding tabs as well, which is why I'd rather see a more broad API that allows hiding tabs. The question I'm really wondering is whether it's worth the burden supporting the group API. Also, in your API, I wouldn't store a list of tabs for each group. I'd rather have browser.tabs.query/update/.. support group: "ID" as property, it'll integrate more smoothly with the current APIs. Another extra API could be added called browser.tabs.queryGroups(); to list the group names/IDs. That's how I would have seen the API. > Currently there are some very different UIs for Tab Groups each having > an appeal for different users. I don't think Firefox should be burdened > with a native UI for this, as it may just be dead weight for users who wish > to use a different UI, and one more thing for Mozilla to maintain. I > believe there is no concern that the API would end up without a UI. Myself > and others, whom I am fairly certain would include Luis, would be ready to > provide an interface. I agree it is an unusual practice, however I feel in > the scenario I have lined out it would actually be less burdensome on > Firefox development. However I concede that there may be ramifications of > this of which I am unaware. Actually, it does take some burden maintaining such an API, it's basically supporting the whole backend of TabGroups which involves lots of code, this is why there are some meetings to carefully pick and decide which APIs go through. If you can find the bug where they removed tab groups, the patches should show how much backend code it involved. > The suggestion that chrome.runtime is the answer only means that it would be > up to one addon to provide the API, and (if harmony is to be maintained) all > other addons would need to rally around it. Also, the addon providing the > API would need to receive messages from other addons to manage groups based > on other addons' requests. There is the potential breakage for dependent > addons anytime the host addon changes its API. All in all this to me is a > fragile condition. I believe that a native API would finally provide a > cohesiveness for a concept that has long been lacking in that. I don't think the API changing/harmony is a real concern. Stylish exposes an API that has never actually changed, and a lot of add-ons are using it. It has worked quite well. An API is unlikely to change unless the purpose of the add-on changes. Also, the runtime API doesn't require the main add-on to explicitly receive messages from add-ons on there request. The only requirement is that the add-on needs to know the add-on ID of the main add-on (which is provided on AMO), and then the main add-on would receive any message that is sent to it.

Thanks for your input Tim. Just a few of comments: > Also, in your API, I wouldn't store a list of tabs for each group. I'd rather > have browser.tabs.query/update/.. support group: "ID" as property, it'll integrate > more smoothly with the current APIs. Another extra API could be added called > browser.tabs.queryGroups(); to list the group names/IDs. That's how I would have > seen the API. It sounds like you are saying you don't want a sort of "global" "TabGroups" object at all. If I follow correctly, the group name and ID would only be associated with each tab, and it would be up to the addon to sort everything out. Sure, I think that would be okay, and as you say it would flow better with the current APIs. The main thing is that we would establish a common API for groups for IDs and names. > Actually, it does take some burden maintaining such an API, it's basically > supporting the whole backend of TabGroups which involves lots of code, this > is why there are some meetings to carefully pick and decide which APIs go > through. If you can find the bug where they removed tab groups, the patches > should show how much backend code it involved. I don't think you can compare what is being suggested here with the removal of Panorama, which was an enormous amount of code mostly related to the UI. It seems to me that what we are talking about here is extremely minimal, and so rudimentary in concept that it is unlikely to need to change. > The main question I have is: Should the tab bar UI only display the active > group like the current tab groups add-on ? If yes, that's my main concern. I > think the suggested API is too specific to the current Tab Groups add-on. > Especially if this API replaces the hidden API. There are tons of ways to do > tab groups, you could group them as a tree, you could group them as a stack > (like Opera 12). And the suggested API doesn't really work for these > use-cases. There are also tons of use-cases to hiding tabs as well, which is > why I'd rather see a more broad API that allows hiding tabs. I concede that it would be good to let addons hide tabs in the tabs bar if they wish using a `hidden` API, rather than forcing that behavior in the `groups` API. I personally believe that it is important for addons to have the option of being able to hide non-active group tabs. Even with the use of tab groups, many users still like to use the tabs bar, and it would be important to many of them that the clutter of irrelavant tabs are hidden. Otherwise to many of them it would be, "what is the point of tabs groups?" So how about if we do this for starters: "groups" API: Assigns ID and name to each tab with read/write access, through browser.tabs.query()/browser.tabs.update() Bonus: "queryGroups" API: browser.tabs.queryGroups() "hidden" API: show/hide tabs, access hidden state, through browser.tabs.query()/browser.tabs.update() I agree, separating the "groups" API and the "hidden" API would be more flexible, as you have pointed out. Here we would have the essentials of a common API for groups. *Perhaps* in the future if it seems meet to do so, an additional API could be added which could be a wrapper for the "groups" API and would provide convenience methods such as `newGroup`, `deleteGroup`, `renameGroup`, `moveTabsToGroup`, but I would be very happy to just see the minimal.

And of course in addition to the above comment, I would like to see `hidden` and `groups` data stored along with the current SessionStore data.

After further discussion we're going to wontfix this particular implementation idea in favor of working on a comprehensive tab management requirements doc in bug 1333837. This would allow us to have tab management that would be properly supported by backend code.

(In reply to Kevin Jones from comment #31) Sorry for the late reply. > It sounds like you are saying you don't want a sort of "global" "TabGroups" > object at all. If I follow correctly, the group name and ID would only be > associated with each tab, and it would be up to the addon to sort everything > out. Sure, I think that would be okay, and as you say it would flow better > with the current APIs. The main thing is that we would establish a common > API for groups for IDs and names. I would say tabs.{query/update}Groups() could work similarly to tabs.{query/update}. That covers pretty much everything from renaming, adding, removing, listing groups. > > Actually, it does take some burden maintaining such an API, it's basically > > supporting the whole backend of TabGroups which involves lots of code, this > > is why there are some meetings to carefully pick and decide which APIs go > > through. If you can find the bug where they removed tab groups, the patches > > should show how much backend code it involved. > > I don't think you can compare what is being suggested here with the removal > of Panorama, which was an enormous amount of code mostly related to the UI. > It seems to me that what we are talking about here is extremely minimal, and > so rudimentary in concept that it is unlikely to need to change. > > > The main question I have is: Should the tab bar UI only display the active > > group like the current tab groups add-on ? If yes, that's my main concern. I > > think the suggested API is too specific to the current Tab Groups add-on. > > Especially if this API replaces the hidden API. There are tons of ways to do > > tab groups, you could group them as a tree, you could group them as a stack > > (like Opera 12). And the suggested API doesn't really work for these > > use-cases. There are also tons of use-cases to hiding tabs as well, which is > > why I'd rather see a more broad API that allows hiding tabs. > > I concede that it would be good to let addons hide tabs in the tabs bar if > they wish using a `hidden` API, rather than forcing that behavior in the > `groups` API. I personally believe that it is important for addons to have > the option of being able to hide non-active group tabs. Even with the use > of tab groups, many users still like to use the tabs bar, and it would be > important to many of them that the clutter of irrelavant tabs are hidden. > Otherwise to many of them it would be, "what is the point of tabs groups?" > > So how about if we do this for starters: > > "groups" API: > Assigns ID and name to each tab with read/write access, through > browser.tabs.query()/browser.tabs.update() > > Bonus: "queryGroups" API: > browser.tabs.queryGroups() Possibly with updateGroups to update groups yes. > "hidden" API: > show/hide tabs, access hidden state, through > browser.tabs.query()/browser.tabs.update() The proposal sounds good. I think we should focus on listing the requirements for that "tabmanagement API"

hidden property is part of bug 1384515 now.