Open Bug 1940631 Opened 5 months ago Updated 3 days ago

[meta] Implement tabGroups WebExtensions API

Categories

(WebExtensions :: General, enhancement)

Product:
WebExtensions
Component:
General
Type:
enhancement
Points:
5

Tracking

(Not tracked)

People

(Reporter: yuki, Unassigned)

References

(Blocks 2 open bugs)

Details

(Keywords: meta, Whiteboard: [fidefe-tabgrps][addons-jira])

Nightly has the tab grouping feature (mainly for the vertical tabs mode?) but it looks completely inaccessible for WebExtensions addons. We need the way to access tabs group information to make some type addons compatible with the feature.

  • Currently tabs in a collapsed group is visually hidden on the native tab bar, but still visible with WebExtensions API. They looks to have a state different from hidden:true. So we may need something new state corresponding to this.
  • APIs around contextual identities (containers) look to be good references for tab groups. ex: Something new property to present tab groups information on each tab similar to cookieStoreId, for example tab = { id: xxx, url: xxx, .. tabGroupId: XXX }.

Sorry if it is already discussed in any existing bug.

Sorry I didn't research well before posting. I've realized that Chrome already has tabGroups API for this purpose.
https://developer.chrome.com/docs/extensions/reference/api/tabGroups?hl=en

Summary: Need WebExtensions API to access to tab groups information → Need to implement tabs.tabGroups WebExtensions API to access to tab groups information

Chrome's tab has a property groupId

Summary: Need to implement tabs.tabGroups WebExtensions API to access to tab groups information → Need to implement tabGroups WebExtensions API to access to tab groups information
Depends on: tab-groups
See Also: → 1927769

We currently don't consider this to be part of the tab groups MVP, but would instead address this post-MVP. Will, do you think that's acceptable or a no-go in terms of causing compatibility issues for add-ons?

Flags: needinfo?(wdurand)
Blocks: tab-groups
No longer depends on: tab-groups
Whiteboard: [fidefe-tabgrps]
Points: --- → 5
Summary: Need to implement tabGroups WebExtensions API to access to tab groups information → Implement tabGroups WebExtensions API

(In reply to Dão Gottwald [:dao] from comment #3)

We currently don't consider this to be part of the tab groups MVP, but would instead address this post-MVP. Will, do you think that's acceptable or a no-go in terms of causing compatibility issues for add-ons?

Lets get the MVP out of the door first, and then we can work on the WebExtensions API based on Chrome's one.

Flags: needinfo?(wdurand)

Although we haven't planned/started the implementation, we have looked at the feasibility of implementing this before.

Additionally, Chrome is actively soliciting feedback in the WECG when additional changes to the tabGroups API are proposed, e.g. at https://github.com/w3c/webextensions/issues/749

Severity: -- → N/A
Priority: -- → P3
Whiteboard: [fidefe-tabgrps] → [fidefe-tabgrps][addons-jira]
Blocks: 1946975

Please make it possible for add-ons to hide/unhide tab groups and their indicators on the tab bar.
This would allow add-ons to create an implementation of workspaces (= collection of individual tabs and/or tab groups), comparable to what already exists in Vivaldi.

Example: the Simple Tab Groups add-on could hide native tab groups made in STG-group 1 when switching to STG-group 2, and unhide these native tab groups again when switching backing to STG-group 1.

These hidden tab groups could be added to the existing "Hidden tabs" menu item (to be renamed then) in Firefox.

PS. If anyone knows of a Bugzilla item referring to a native workspace implementation in Firefox, please give me a pointer. Thanks!

Blocks: 1949139

(In reply to BelFox from comment #6)

PS. If anyone knows of a Bugzilla item referring to a native workspace implementation in Firefox, please give me a pointer. Thanks!

Could not find any issue related to it.

Just this https://connect.mozilla.org/t5/ideas/workspaces-%C3%A0-la-opera/idi-p/66

I think it's worth opening a feature request for it. If you choose to do it, post the link back here, please!
(even if there was one already, it would just be marked as dup...)

Blocks: 1956278
Priority: P3 → P1
Depends on: 1959713
Depends on: 1959714
Depends on: 1959715
Depends on: 1959716

I created separate bugs to track the implementation of individual APIs to introduce the awareness of tab groups in the extension APIs:

Not scheduled in these yet is the tabGroups API itself, which would be necessary if extensions want to manage tab groups at the tab groups level (rather than at the individual tab level). These can be followed up upon in this bug (or other new dependencies).

Depends on: 1959730
No longer blocks: 1949139
No longer blocks: 1956278
See Also: → 1960104
Depends on: 1961539
Depends on: 1961657
Depends on: 1961660
Depends on: 1961663

(In reply to Rob Wu [:robwu] from comment #8)

I created separate bugs to track the implementation of individual APIs to introduce the awareness of tab groups in the extension APIs:

Not scheduled in these yet is the tabGroups API itself, which would be necessary if extensions want to manage tab groups at the tab groups level (rather than at the individual tab level). These can be followed up upon in this bug (or other new dependencies).

Being able to (un)hide tab groups, like already possible with tabs, comes to mind. I remember a drawer/menu was added to expose hidden tabs. This could be extended with hidden tab groups. Could you add these as well (as a placeholder maybe)?

(In reply to BelFox from comment #9)

(In reply to Rob Wu [:robwu] from comment #8)

Not scheduled in these yet is the tabGroups API itself, which would be necessary if extensions want to manage tab groups at the tab groups level (rather than at the individual tab level). These can be followed up upon in this bug (or other new dependencies).

Being able to (un)hide tab groups, like already possible with tabs, comes to mind. I remember a drawer/menu was added to expose hidden tabs. This could be extended with hidden tab groups. Could you add these as well (as a placeholder maybe)?

Your request is covered by the "collapsed" property of the tabGroups API, which has a patch in bug 1961539 + bug 1961657. These patches will land within the next few days, in time for Firefox 139.

(In reply to Rob Wu [:robwu] from comment #10)

(In reply to BelFox from comment #9)

(In reply to Rob Wu [:robwu] from comment #8)

Not scheduled in these yet is the tabGroups API itself, which would be necessary if extensions want to manage tab groups at the tab groups level (rather than at the individual tab level). These can be followed up upon in this bug (or other new dependencies).

Being able to (un)hide tab groups, like already possible with tabs, comes to mind. I remember a drawer/menu was added to expose hidden tabs. This could be extended with hidden tab groups. Could you add these as well (as a placeholder maybe)?

Your request is covered by the "collapsed" property of the tabGroups API, which has a patch in bug 1961539 + bug 1961657. These patches will land within the next few days, in time for Firefox 139.

I'm following the development of the "Simple Tab Groups" (STG) add-on and there's been numerous requests from people who would love to use a combination of STG and the new native tab groups.

The add-on currently works based on hiding / unhiding tabs, so when switching from one STG group that contains a Firefox native tab group to another STG group will hide all the tabs from the native tab group, which unfortunately leaves the native group's label in the tab bar with no visible tabs inside.

So if I understand correctly what the "collapsed" property is supposed to do, that's unfortunately insufficient to properly support said use case. We would be really happy to see an API function to control full visibility of the native tab groups in order to be able to smoothly integrate STG and native tab groups. This would basically achieve a two-layered grouping system.

Alternatively, it might be worth considering to tie the native tab group's visibility to it's inner tabs and hide the group when all tabs in the group are hidden as a pragmatic solution, but that will have potentially unwanted side-effects for other use-cases.

Thanks for your consideration!

Keywords: meta
Summary: Implement tabGroups WebExtensions API → [meta] Implement tabGroups WebExtensions API
Depends on: 1962475
Depends on: 1962592

(In reply to Phil from comment #11)

I'm following the development of the "Simple Tab Groups" (STG) add-on and there's been numerous requests from people who would love to use a combination of STG and the new native tab groups.

The add-on currently works based on hiding / unhiding tabs, so when switching from one STG group that contains a Firefox native tab group to another STG group will hide all the tabs from the native tab group, which unfortunately leaves the native group's label in the tab bar with no visible tabs inside.

So if I understand correctly what the "collapsed" property is supposed to do, that's unfortunately insufficient to properly support said use case. We would be really happy to see an API function to control full visibility of the native tab groups in order to be able to smoothly integrate STG and native tab groups. This would basically achieve a two-layered grouping system.

Alternatively, it might be worth considering to tie the native tab group's visibility to it's inner tabs and hide the group when all tabs in the group are hidden as a pragmatic solution, but that will have potentially unwanted side-effects for other use-cases.

Thanks for your consideration!

Could you open a new feature request that blocks this ticket, and explain what you want?

When I read your question, I wonder whether your use case could also be addressed by saving the tab group metadata in your extension, and then ungrouping the hidden tabs. And when the user wants to show it again, to regroup the (hidden) tabs.

In Firefox's UI, currently the visible tab groups are the source of truth. Visually hiding tab groups from the tab strip but keeping it around, e.g. in the context menus would be rather strange.

I wonder what API and desired behavior you have in mind.

(In reply to Rob Wu [:robwu] from comment #12)

(In reply to Phil from comment #11)

I'm following the development of the "Simple Tab Groups" (STG) add-on and there's been numerous requests from people who would love to use a combination of STG and the new native tab groups.

The add-on currently works based on hiding / unhiding tabs, so when switching from one STG group that contains a Firefox native tab group to another STG group will hide all the tabs from the native tab group, which unfortunately leaves the native group's label in the tab bar with no visible tabs inside.

So if I understand correctly what the "collapsed" property is supposed to do, that's unfortunately insufficient to properly support said use case. We would be really happy to see an API function to control full visibility of the native tab groups in order to be able to smoothly integrate STG and native tab groups. This would basically achieve a two-layered grouping system.

Alternatively, it might be worth considering to tie the native tab group's visibility to it's inner tabs and hide the group when all tabs in the group are hidden as a pragmatic solution, but that will have potentially unwanted side-effects for other use-cases.

Thanks for your consideration!

Could you open a new feature request that blocks this ticket, and explain what you want?

When I read your question, I wonder whether your use case could also be addressed by saving the tab group metadata in your extension, and then ungrouping the hidden tabs. And when the user wants to show it again, to regroup the (hidden) tabs.

In Firefox's UI, currently the visible tab groups are the source of truth. Visually hiding tab groups from the tab strip but keeping it around, e.g. in the context menus would be rather strange.

I wonder what API and desired behavior you have in mind.

Thanks for your quick reply!

I've forwarded your suggestion to the STG author. If we still think it's necessary, we'll open a feature request with further details.

Hey everyone—would love to be able to rename a tab group from an extension. Something like:

browser.tabGroups.update(groupId, { title: "My Project" });

Right now there’s no way to set or change a group’s name programmatically, and having that would really help automate workflows. Thanks!

(In reply to corismix from comment #14)

Hey everyone—would love to be able to rename a tab group from an extension. Something like:

browser.tabGroups.update(groupId, { title: "My Project" });

Right now there’s no way to set or change a group’s name programmatically, and having that would really help automate workflows. Thanks!

This was implemented in bug 1961657, available in Firefox 139. The tabGroups API is not documented yet, but that will be worked on next week.

(In reply to Rob Wu [:robwu] from comment #15)

(In reply to corismix from comment #14)

Hey everyone—would love to be able to rename a tab group from an extension. Something like:

browser.tabGroups.update(groupId, { title: "My Project" });

Right now there’s no way to set or change a group’s name programmatically, and having that would really help automate workflows. Thanks!

This was implemented in bug 1961657, available in Firefox 139. The tabGroups API is not documented yet, but that will be worked on next week.

Thank you for the quick reply :)

Hey Rob, can we close this, as I believe we're done with regards to the documented tabGroups API?

Flags: needinfo?(rob)

We have fully implemented all specified parts of the extension API to manage tab groups, with groupId, tabs.group(), tabs.ungroup() in Firefox 138, and the tabGroups API in Firefox 139.

The tabGroups API currently only manages tab groups with any visible state. If there are tab groups that should be exposed but don't have any (visible) tabs in any window, then we don't expose these. If there is a desire to expose these, then we need a follow-up for that.

The sessions API does currently NOT expose groupId, and is tracked in bug 1927769.

Anything beyond what we have implemented should be tracked in separate bugs. Can you confirm that we have these bugs, and if so, close this bug?

Flags: needinfo?(rob)
Depends on: 1965007
Depends on: 1965057
Depends on: 1965083
Depends on: 1963825
Depends on: 1963830
Depends on: 1966617

It would be convenient if extensions had access to some of the tab group operations available through the tab group menu items and also could modify closed/saved groups.

For example:

tabGroups.query({closed: true}) - (tab groups would have a 'closed' property that may be queried)
tabGroups.close(groupId) - (saves and closes group)
tabGroups.delete(groupId) - (deletes a closed or non-closed group)
tabGroups.ungroup(groupId) - (ungroups all tabs in a non-closed group)
tabGroups.open(closedGroupId, {newWindow: true}) - (opens a closed group in a new or existing window, 'newWindow' defaults to false)
tabGroups.update(closedGroupId, {urls: [...]}) - (closed groups would have a 'urls' property that may be updated)
tabGroups.update(closedGroupId, {color: "...", title: "..."}) - ('color' and 'title' properties of closed groups may be updated)

Would it be worth creating new bugs/issues for any of these tabGroups API enhancements? Are any of these not reasonable?

It looks like this issue (https://github.com/w3c/webextensions/issues/715) requested many of the above tabGroups API enhancements (plus pinning/unpinning groups on the bookmarks bar in Chrome). It didn't go anywhere or maybe needs further discussion. Writing out a detailed or improved enhancement proposal in that issue is outside my wheelhouse, if that's the best way to request these new features, though...

It would be nice for extensions to be able to add custom items to the tab group right-click context menu.

(In reply to Rob Wu [:robwu] from comment #12)

When I read your question, I wonder whether your use case could also be addressed by saving the tab group metadata in your extension, and then ungrouping the hidden tabs. And when the user wants to show it again, to regroup the (hidden) tabs.

In Firefox's UI, currently the visible tab groups are the source of truth. Visually hiding tab groups from the tab strip but keeping it around, e.g. in the context menus would be rather strange.

I don't think this would be strange at all. In fact, if a user installs an extension that can hide tabs—whether it be OneTab, Tab Stash, or Simple Tab Groups—having those tab groups lingering after all the tabs within the group have been hidden is what the user would see as odd.

I also think that making extension developers handle this is a bad approach. There's a lot to juggle, and it will be extremely error-prone for a long time. Buggy extensions make Firefox look bad in turn. Look at how much extension developer feedback you've got. Let's face it, hardly anything. Most of it has been from affected users of the extensions impacted. By the time the extension devs have ironed out any bugs, the reputational damage is done.

I do think we should allow WebExtension developers to manage this if they choose to, but by default, hiding tab groups when all tabs within are hidden is absolutely the way to go.

You could cater to WebExtension developers who want to handle it themselves by adding an option to browser.tabs.hide(). Something like this (with a different property name, possibly):

browser.tabs.hide(tabIds, {
  dontHideTabGroup: true
})

This would tell Firefox not to hide the tab group, if the tab being hidden is in a tab group, and it's the last visible tab in the group.

In terms of where you would show the hidden tab groups, this would largely be up to Firefox's Product team. But in my opinion, users who have installed extensions with the tabHide permission are power users and are accustomed to having a Hidden tabs menu in the List all tabs menu. Therefore, the hidden tab groups could be shown in that same location.

Again, I'm not the Firefox product owner, but there would be no point showing the hidden tab group in the Recent tab groups area because clicking on it would do nothing. You could hide it there, or disable it and suffix it with "(Hidden)".

There would still be value in showing it in the "Add tab to group" menu, though, as doing so would do something. Make the tab group visible again and put the tab within it.

I've developed an workspaces add-on that handles native tab groups well (thanks to the new Tab Groups API), and found it relatively easy to degroup and regroup tabs in the same step where I need to hide/show them anyway.

Though, it will break all the older add-ons, which may not be necessary.

This is a meta-bug tracking other bugs. If you have feature requests, please file create a new bug and link to this bug.

Priority: P1 → --
You need to log in before you can comment on or make changes to this bug.