(1357214) interop: tab groups: Firefox parity with the tabs.group method of the chrome.tabs API in Google Chrome

Add-ons
#1

Not to be confused with Mozilla bug 1410548 - Tab hiding

Comment https://www.reddit.com/r/firefox/comments/8ipefx/-/dytyf1g/?context=1 draws attention to four extensions. The three that do not use containers:

I ran some quick tests with Firefox 60. As far as I can tell:

  • a group that is created by one extension is not usable by an another extension.

Will there be no WebExtensions API for groups?

Also AFAICT none of the extensions allows a group to span multiple windows.

Please, am I missing something?

Incidentally …

Development of an extension by Mozilla, or someone at Mozilla

Was the October 2017 talk of a straight up rewrite/replacement (for Tab Groups) … from a Mozilla developer wishful thinking?

I imagined that something from Mozilla might become an experiment in Firefox Test Pilot.

Can't customize my tab appearance anymore
#2

From @ntim in the Reddit thread:

Why would you need to use 2 different tab group extensions ?

I don’t expect any single extension to serve all purposes.

I don’t think Mozilla has official plans to make its own alternative though. Why would it make it a difference if the add-on is built by Mozilla ?

I wondered whether the October 2017 talk was wishful thinking, because at the time there was no pointer to work in progress by anyone at Mozilla.

I’m only aware of https://github.com/nchevobbe/tabspace which is made by a Mozilla developer as a side project (it’s not finished though).

Thanks!

@nicolas_chevobbe please see the opening post, the emphases; any thoughts?

TIA

#3

These extensions could expose communication protocols of their own, like container extensions and some others do if interaction is so complicated. (Other examples for cross-extension communication can be found at https://github.com/freaktechnik/awesome-extension-apis)

1 Like
#4

Thanks. I’ll try to rope in thoughts from developers at https://github.com/Quicksaver/Tab-Groups/issues/535, which seems to be a favoured meeting place for developers of possible alternative extensions.

Generally

I see pockets of brilliance, but the overview seems to lack cohesion, in places. Things such as:

  • how groups can/should complement containers.

A brief comparison

For Firefox containers:

  • emphasis on containment (think: restriction) and privacy, without movement from one container to another
  • a significant user base requires movement, so we have extensions such as Conex that may require a careless approach to privacy, for movement to be reasonably bug-free
  • a container can span multiple windows
  • a variety of extensions can work with any container

– and then, for tab groups, AFAICT (correct me please if I’m wrong):

  • no groups API
  • limited freedom of movement
  • group restriction to a single window
  • a group that is created by one extension is not usable by an another extension – so there’s diversity without complementarity, although things such as awesome-extension-apis might help to plug the gap(s)

– it’s a bit of a mash … not cohesive :-/

#5

Dropping a few notes. You don’t need a specific “group” API to implement something like tab groups. In fact, there previously also was no API for groups.

When your extension needs to switches tabs, it can iterate over all tabs, check if each tab should be visible and hide/show them as required. That’s how I did it, and that’s also how Panorama did it. The only tricky part is to find some kind of unique tab identifier, as you cannot use the URL of a tab for obvious reasons. Quickly glancing over the current APIs, using the tab ID shold be fine, but I have not looked into more detail.

Also, just for the record:

I created this extension as a replacement for Panorama, which was removed due to really low usage numbers. Removing it from the core was the right decision, but I depended on tab grouping for my workflow back then, so I created something that got the job done for me. These days, I simply don’t need it anymore.

Although I am indeed a Mozilla staff, what I do in my free time stays there. This extension was not related to my work in any way, and in fact, writing UI features couldn’t be further away from what I actually do for my living. :slight_smile:

3 Likes
#6

Thanks for joining the discussion :+1:

So (a question for anyone) …

… if a group is to span multiple windows, the extension might:

  • iterate over all tabs in all windows and
  • use a combination of the tab ID number and its window ID number to uniquely identify the tab

– something like that?

Then … what would happen when a tab in a group is moved, by the user, from one window to another?

#7

Tabspace is still under development, but I don’t spend any time on it since 3 months or so.
This is my first attempt at creating a webextension, so I’m not sure I can have good insights here (and I’m not from the extension team).
However, it feels to me that all the grouping logic can be made by the extension itself, without having a grouping API in FF.

Then it’s up to you to mix that up with containers or not.

2 Likes
#8
#9

From https://bugzilla.mozilla.org/show_bug.cgi?id=1357214#c33:

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

… tab groups has become the only WebExtensions area where parity with Chrome is denied (or words to that effect).