Compatibility issue between Simple Tab Groups and native tab grouping (browser.tabs.groups)

[suchydrot]

Describe the bug Mozilla has finally added a native option for basic tab grouping browser.tabs.groups, link. Unfortunately, it doesn't work well in conjunction with Simple Tab Groups. When I set browser.tabs.groups.enabled = true in about:config, everything seems to work at first glance, and I can use Simple Tab Groups alongside the built-in tab grouping, which is IMHO an awesome combo. However, as soon as I switch to a different group in Simple Tab Groups, I can see the names of grouped tabs created via browser.tabs.groups from another group.

To Reproduce Steps to reproduce the behavior:

1. browser.tabs.groups.enabled = true in about:config
2. Open e.g. any 5 new tabs
3. Drag one tab over another to create native group (you may name it for better visual)
4. Create new Simple Tab Group group and open it
5. Now you can see grouped tabs label from another Simple Tab Groups group (label is visible but expanding does not work)

Expected behavior Hide native grouped tabs label(s) from another Simple Tab Groups group(s)

Desktop:

• OS and version: Windows
• Firefox version: 134
• Simple Tab Groups version: 5.2

[swainasish]

Same issue. Please fix this ASAP. Does anyone find any solution ?

[Wacky-Wombat]

Same issue. Please fix this ASAP. Does anyone find any solution ?

Same here. Quite annoying. :/

[rockimiq]

bump. id also like to see this implemented at some point.

for example: i have two STG groups, one for newspapers of my own country and then international newspapers. for the international ones it'd be nice to group the tabs by continent/region, but doing it in STG groups would be overkill (only 2-4 tabs per group), but without any separate grouping the tabs are a bit cluttered. combining the functionality of both would be amazing.

[philg-dev]

I'm fairly sure, that at this point there isn't even an API that web extensions can use to control / manipulate the new Firefox native tab groups. I've searched the web and the MDN for a bit and couldn't find anything and chatGPT also claimed that there isn't any implementation of a JavaScript API for web extensions to interact with the new native FF tab groups yet and apparently there's not even a roadmap for it yet(?)

It's not super surprising, to be honest - given that access to the feature is still completely gated behind an about:config flag and it's not even available yet through "Firefox Labs" experimental features. So hopefully we'll get news about an API soon when the feature becomes completely available to the "normal" non-tech-savvy users.

I would love to be proven wrong in this case,... but if the information I found is correct, then there's basically nothing we can do about this issue right now.

Edit: Bugzilla Ticket about the implementation of an API: https://bugzilla.mozilla.org/show_bug.cgi?id=1940631

Edit 2: From what I've seen from a comment in the bugzilla ticket, it looks like some basic interactions are supported in the meantime (not sure if they made their way into a release / nightly yet though). But regarding the tab group names / color etc. there's nothing yet. So none of these changes seem to provide a viable way to improve compatibility between STG and native tab groups.

Edit 3: There's apparently a "collapsed" property in the TabGroups API that is being implemented right now, but no specific news about hiding native tab groups entirely. I've stated our situation in the BugZilla Ticket in this comment. Let's hope they'll consider adding that functionality.

[creativecoder]

The workaround I've been using is to put the following in chrome/userChrome.css within my Firefox profile folder

#tabbrowser-tabs tab-group:not(:has(.tabbrowser-tab:not([hidden]))) {
    display: none !important;
} 

This hides Firefox native tab groups that don't have any tabs in the current Simple Tabs group. It's possible this will break in a future update, but it's working for now.

More about userChrome.css if you haven't used it before.

[philg-dev]

@creativecoder living up to your name there - that's indeed an interesting approach.

For anybody who is not familiar or comfortable with custom CSS "hacks" like this, I would advise them to steer clear from such a workaround. It might work for the time being, but then people forget they implemented it and it becomes a foot gun when anything changes.

Nonetheless, I like it, as I'm also writing a lot of Stylus userstyles - but I still won't use it, because I don't even care about the native tab groups yet.

[philg-dev]

@Drive4ik in reply to my comment on the Firefox BugZilla, Rob Wu asked to create a feature request that explains what kind of API we have in mind.

He did mention the possible "workaround" of disbanding / recreating native tab groups whenever STG switches groups.

https://bugzilla.mozilla.org/show_bug.cgi?id=1940631#c12 Quoting Rob Wu here for convenience:

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.

Do you think the approach that he suggested is feasible? It sounds like they're not really fond of the idea of adding a way to hide / unhide native tab groups... So we would need a proper technical reasoning in order to convince them. Feel free to add a reply or feature request on BugZilla directly, if you see fit. I'll leave it at that for now.

[rubcap]

The workaround I've been using is to put the following in chrome/userChrome.css within my Firefox profile folder

#tabbrowser-tabs tab-group:not(:has(.tabbrowser-tab:not([hidden]))) { display: none !important; }

This hides Firefox native tab groups that don't have any tabs in the current Simple Tabs group. It's possible this will break in a future update, but it's working for now.

More about userChrome.css if you haven't used it before.

HERO!! 🦸‍♂️ This will boost my workflow using STG even more.

If only @Drive4ik could incorporate this or another solution (e.g. the one proposed in the BugZilla ticket) in STG by default, that would be great!

[creativecoder]

The workaround I've been using is to put the following in chrome/userChrome.css within my Firefox profile folder ...

Know that this has needed tweaks for nearly every recent Firefox release to keep it working correctly. If you're using this, anticipate that it may cause issues when Firefox updates, like not being able to drag and drop to re-order tabs. With that said, here's the current userChrome CSS that's working for me:

#tabbrowser-tabs tab-group:not(:has(.tabbrowser-tab:not([hidden]))) .tab-group-label-container {
    margin: 0 !important;
    max-height: 0 !important;
    max-width: 0 !important;
    padding: 0 !important;
    visibility: hidden !important;
}

---

He did mention the possible "workaround" of disbanding / recreating native tab groups whenever STG switches groups.

In terms of UX, I think this could actually be a good way to handle it. When you're in a STG tab group, and looking to use Firefox native groups to do sub-grouping, it's odd that all Firefox tab groups are available in the right-click menu ("Add Tab to Group"), even if some of those groups are not currently visible (using the workaround, above). If the available Firefox tab groups were specific to the visible STG group, that would make more sense. In other words:

• STG groups for top level tab grouping
• Firefox tab groups for sub-grouping within the current STG group,
• with each STG group having it's own set of Firefox tab groups

I find this combination really handy. STG groups are like workspaces for me, I switch to the one specific to the current project or task I'm working on. Then Firefox tab groups let me group the visible tabs in the current "workspace" when I need another level of organization.

[harshid86]

Given the lack of feedback from actual extension devs on https://bugzilla.mozilla.org/show_bug.cgi?id=1940631, I've provided my thoughts on how Firefox should handle tab groups with hidden tabs.

Ideally, I would have wanted this feedback to come from the actual extension devs, as they would know best what they need/want from Firefox to make this work. But at this rate, users are going to end up with hacky solutions or buggy extensions (IMO).

If you agree/disagree with my suggestion, feel free to chime in on the Bugzilla ticket.

[mjtorn]

#tabbrowser-tabs tab-group:not(:has(.tabbrowser-tab:not([hidden]))) .tab-group-label-container { margin: 0 !important; max-height: 0 !important; max-width: 0 !important; padding: 0 !important; visibility: hidden !important; }

Checked my profile in about:support and created chrome/userChrome.css with this in it.

Everything seems just as by default on 140.0.4 / Linux.

[mjtorn]

Is this also the correct issue for this one thing, which I don't think anyone made real noise about. Sorry if I didn't look hard enough.

Closing a window with an STG group, and native groups as sub-groups, closes as expected. Opening a new window, and the STG group in it, will open the STG group with all the native-group tabs open, like the groups ungrouped.

Then they gotta be closed and the native groups restored.

This is real annoying, as I have one STG group where I really can't manage all the stuff that's happening without native-group sub-grouping. Made worse by some tabs that should always be visible, like pinned but not to a literal window.

My workaround? A canary tab 😆 So I don't touch the first tabs in the window and close all the maybe 66 tabs to the right of this one (eg. weather report site) tab, then restore and (only for clarity) collapse the native groups one-by-one.

I could prefix the native tab groups with mnemonics about which STG they belong to if I really had a ton of this use case, but this is not exactly fun.

Am I alone with this probably very niche way?