Multi-account-containers: Embrace the use of containers for tab management

[aleth]

While not its primary purpose, the fact that the containers implementation provides

• a pretty way to group tabs by colour-coding
• a way to temporarily hide containers

means that a lot of people will probably use it to manage their tabs. While the separation of cookies etc will be less important for them in that case, there's no contradiction, quite the opposite: users may end up using contextual identities when context separation would be appropriate without fully understanding what it is.

The main stumbling block for using containers in this way is probably #311 or #317, as otherwise the presumption is that the user has decided she will need a container before opening the first tab, which seems likely for banking but not so much for other use cases. The workflow I have in mind is, for example, "let me just mark this bunch of tabs under 'travel' so I can hide them for now, but get back to them later".

Maybe this has been obvious from the start of the design process, in which case I apologize for filing this issue. But if not, I just wanted to point out that with a couple of additional features added, containers make a good replacement for e.g. tab groups (the addon version of which will no longer work after gecko 57).

[nol13]

Can I add, a change to go along with the one mentioned above, to more conveniently be able to only see tabs from one container, and have new tabs open in that container by default. (opening in current container by default maybe not as important if you could easily to move tabs between container though, as long as I don't have to stop and think which container to open into every time I open a tab) As is it takes 3 clicks to hide a group.

[escapewindow]

I'm going to miss tab groups when it dies... it'll be a productivity hit. Adding tab management to container tabs would help mitigate that loss.

[jxn]

Yes, Tab Groups and Containers were meant for each other. It's just a shame that one is coming of age as the other is fading away.

[groovecoder]

See also https://github.com/mozilla/testpilot-containers/issues/328, which should count for an additional +5 on this issue.

[JohnLGalt]

This actually fits rather well into what I wrote up as a RFF on the discourse site.

https://discourse.mozilla-community.org/t/prevent-showing-hidden-container-from-creating-a-new-tab/14391

[klint]

I totally agree with this request and also with this statement above:

Yes, Tab Groups and Containers were meant for each other. It's just a shame that one is coming of age as the other is fading away.

See my own entry in the discussion about that: https://discourse.mozilla-community.org/t/could-panorama-feature-be-brought-back-to-firefox/14672

And thanks for containers as they are already :) one of the greatest enhancement of Firefox lately. Hope it will be built-in soon.

[rastapopougros]

I have always almost 200 tabs, permanently. So the abandoning of TabGroups is really an horrible thing to me. :cry:

If anything can help me manage and group all my tabs (I have one group per work project, one group for news, one group for home things, etc), I take, I take, I take!

[dgutov]

I'm going to join the sentiment, but I worry that Containers might not be the best match with my habits of using Tab Groups. Say, I have two groups: "work" and "play". We'd translate "play" to a "default" container, or all non-container tabs.

One:

As I go about my day, I switch between "work" and "play", and open "unaffiliated" tabs in both. Say, Hacker News links. This step might be addressed if tabs open links in the same container by default.

But then, I'd have to log into Hacker News twice.

I also move tabs between groups, like when I decide when I'm going to read something later at home. Is moving tabs between containers supported at all? Ideally, without reloading the page.

Two:

The bookmarks are going to be separated by Containers (right?); I frequently access some of the same bookmarks from the "play" and "work" groups. Although maybe that's not 100% essential.

[mirh]

Very nice point.
Albeit.. Would it really be all that difficult to ask for a new private(/separate) or common(/normal) container at creation time?

[dgutov]

Common meaning "actually just a tab group"? :)

I would like that, of course.

[escapewindow]

I'm thinking of them as containers and views.

A container could have multiple views; this would allow for any of your work projects to be part of the work container, but have its own separate view. Views at this point would be a subset of a single container's tabs, and it would make a lot of sense for containers to support this.

I would also like a view to able to show tabs from multiple containers, at which point views and containers are no longer tied together. I'm not sure if views would continue to be a containers feature at that point, or its own feature. But just getting to the above point, where a container can have multiple views, would be very handy in managing tabs.

[smichel17]

@dgutov

I also move tabs between groups, like when I decide when I'm going to read something later at home. Is moving tabs between containers supported at all? Ideally, without reloading the page.

Check out https://addons.mozilla.org/en-US/firefox/addon/context-plus/

The bookmarks are going to be separated by Containers (right?); I frequently access some of the same bookmarks from the "play" and "work" groups. Although maybe that's not 100% essential.

I'm not sure I understand. Bookmarks separated by container? Unless you're bookmarking a URL with identifiable information in it, you can open a bookmark into whatever container you'd like..

[dgutov]

Check out https://addons.mozilla.org/en-US/firefox/addon/context-plus/

Does it interact well with single page applications, video playback status, existing form input, etc?

Unless you're bookmarking a URL with identifiable information in it, you can open a bookmark into whatever container you'd like

For now, yes. But see https://wiki.mozilla.org/Security/Contextual_Identity_Project/Containers#What_is_.28and_isn.27t.29_separated_between_Containers and https://bugzilla.mozilla.org/show_bug.cgi?id=1213290

[smichel17]

Opinion: I would de-prioritize this issue for now, but prioritize its addition in time for the firefox 56 release, one release before xul support is dropped and the tab groups addon stops working.

@dgutov

Does it interact well with single page applications, video playback status, existing form input, etc?

Haven't tested that much because my primary machine is still on ff52, but I believe it is the functional equivalent of a hard refresh (Ctrl-Shift-R). So, no. However, it's still a vast improvement over the existing workflow. Gets probably 70% of the way there.

For now, yes. But see https://wiki.mozilla.org/Security/Contextual_Identity_Project/Containers#What_is_.28and_isn.27t.29_separated_between_Containers and https://bugzilla.mozilla.org/show_bug.cgi?id=1213290

Oh, wow. That workflow looks so much nicer.

[SXZ1]

@aleth

a pretty way to group tabs by colour-coding

This. IE-like tab coloring when parent tab and all child tabs have the same color is a great feature. It would be great to see it in vanilla Firefox.

[pshem]

I'm another person who installed Test Pilot&Containers thinking Mozilla finally decided to re-implement Tab Groups(https://addons.mozilla.org/en-US/firefox/addon/tab-groups-panorama/). The idea of having:
a) /common
b) /private
containers sounds tailored for me, as I currently have:
a) functional Tab Groups(ie. work, to read, code, games etc.)
b) ICE instances for profile isolation from horrible trackers like Facebook

ICE(https://github.com/peppermintos/ice) was meant for webapps and opening outside links(for example from email) in ICE instances is near on impossible(ok, it is impossible. I just make extra burner profiles, login, 2FA, delete). This is something containers solve and I'll be really grateful for.

One more integration I'd love to see is per container no-script policies. It's not a priority in the short run, as no-script is going through a ~rushed~ _rapid_ Web Extensions rewrite, but I'd love to see it in the long run. This is especially important for Facebook/Twitter/ whose ~hounds~ _trackers_ use the same script sources as the website it's self(and thus unblocking them for the website unblocks them everywhere, which defeats the purpose).

Doing the /private and /common modes would require clear visual distinctions, maybe with transparent stripes(think https://images.duckduckgo.com/iu/?u=https%3A%2F%2Frazzledazzleme.files.wordpress.com%2F2009%2F01%2Fstripe1.png&f=1) on the common tabs?

[mikhoul]

Common meaning "actually just a tab group"? :)

I would like that, of course.

I agree 200% :octocat:

[grahamperrin]

Partly in response to https://github.com/mozilla/testpilot-containers/issues/336#issuecomment-289425819 (I'm in the discussion that @klint began)

I'd love to continue and broaden my embrace of Firefox, but I can not yet see how things such as Firefox containers will work with each other without breaking my workflows. Here:

The window is the container – the user groups things within a container – those things are tabs

[jonathanKingston]

As mentioned in @grahamperrin's thread on discourse I made an extension which does many of the tab management tasks users are wanting.

504 for votes on adding this tab sidebar feature to the experiment.

Whilst this doesn't solve moving to a different container (mostly as mentioned, we have no real solution for this which doesn't impact privacy). It does however make tab creation always visible to the user which ideally will improve the number of times a user opens the wrong container.

After the initial hump of creating a container, I have rarely found I want to move containers. I'm wondering if both assigning a website and container creation can clear up tabs in the wrong container. However I'm not after the same level of tab management that tab groups provide.

[grahamperrin]

An attempt to summarise a handful of key points

1. Test Pilot Containers synchronisation might extend to assignments and containers
2. Test Pilot Containers synchronisation will not extend to cookies, storage, tabs or mobile
3. Container-oriented search will be implemented in the Sea Containers extension, the scope of this enhancment is not yet clear
4. Test Pilot Containers will not allow a tab to be moved from one container to another
5. we might gain Core support for movement of a tab from one container to another.

Much of the technical content, particularly in Bugzilla@Mozilla, is beyond me so @jonathanKingston and colleagues: please correct any false assumptions. Thanks.

References

RapidRelease/Calendar - MozillaWiki

Mozilla bug 1323873 - Allow tabs to change user contexts when navigating

• 2016-12-15
• priority 3 (medium) (probably backlog) since 2017-02-28
• product: Core
• component: DOM: Security
• new, unassigned.

https://github.com/mozilla/testpilot-containers/issues/339#issuecomment-291969002 (2017-04-05) and other comments under _Containers not synchronised · Issue #339 · mozilla/testpilot-containers_

Comment 1 (2017-04-19) under Mozilla bug _1344231 - TestPilot: Add a existing tab to a container_, with reference to Consider a tab context menu option to convert a normal tab to a container · Issue #311 · mozilla/testpilot-containers:

… duplicate … Will leave open if we decide to implement in native.

– and if I understand correctly, in that duplicate context 'convert a normal tab to a container' is to an _existing_ container (not a new container).

Sea Containers sidebar for managing tabs - Test Pilot / Containers - Mozilla Discourse (2017-05-11)

Implement search · Issue #4 · jonathanKingston/sea-containers (2017-05-15)

Thought

With no-one assigned to Mozilla bug 1323873 (above), I doubt that the enhancement will be made before the 2017-11-14 release of Firefox 57.

[groovecoder]

Thank you everyone for the comments and up-votes on this early issue from the Test Pilot experiment. Ideas in this issue are now filed as separate issues for focused up-voting and discussion.

Now that Containers is available on AMO, we're going to start sending more add-on developers to this list of issues to give them ideas for additional Containers add-ons they can build.

So, to help focus the issue list they see, I'm going to close this one. Please upvote and comment on the individual tab-management issues that are also filed here:

https://github.com/mozilla/testpilot-containers/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

[JPFrancoia]

Tabmarks: https://addons.mozilla.org/en-US/firefox/addon/tabmarks/

Best alternative to tab groups I've found so far.

[banhgao]

https://addons.mozilla.org/en-US/firefox/addon/sync-tab-groups/
Same as Tabmarks, plus allowing drag and drop tab.

[escapewindow]

I prefer tree style tab at this point. I generally have <10 groups and I generally want the top 2-3 groups to preserve history and state for frequent context switching, so discarding tabs and putting them in bookmarks doesn't work for that case. The grouped tabs are collapsible to a single row, and can be dragged and dropped on top of each other to group them.

[Deledrius]

Same here. Any replacement which discards a tab's state and history is a non-starter.

[klint]

Just wait for the hide/show tabs API bug to be resolved, and you'll get what you want.

[CamJN]

@klint That's pretty unlikely at this point, the API as it currently stands will discard tabs not just hide them, and there is at least one person in a position of power trying to sabotage that API.

[mirh]

The api as it currently stands isn't doing anything, period, because it's blocked in a review/whiteboard hell.
And the mozilla developer isn't more "sabotaging" the api, than whatever other non-development-related message from a random guy is.
So please, just leave them make whatever even basic api they want, then adding a whatever "do/don't do this" option is prolly going to be a cakewalk.

[grahamperrin]

On topic, please:

Embrace the use of containers for tab management

Closure of this Firefox _Multi Account Containers_ extension issue is not a reason to go off.

---

Off-topic, for alternatives to Tab Groups, you can – with GitHub-based authentication – join either/both of the following discussions:

• Concern about WebExtensions exclusive strategy from add-on authors and users - Mozillians - Mozilla Discourse, which began with focus on Tab Groups
• Favorite WebExtensions? - Add-ons / Contribute - Mozilla Discourse

Thanks.

[stephen304]

I've been using 57 for a week and I think tab containers is almost perfect for tab groups for those who don't mind giving up tab mobility between groups. You can already create your groups and hide ones you're not working with, there's just no way to make it automatically hide other groups other than the one you are currently working with.

If there were a way to automate hiding containers and providing a menu to "switch" by showing a new container and hiding all the other containers automatically, I would be completely satisfied.

[stephen304]

@Deledrius Care to provide context to your thumbs down? I would really like to hear why you don't think containers could be a replacement for tab groups.

[maverick74]

@groovecoder
I'm sorry for bringing this old issue up again but after giving the addon another try i have to ask:

am i missing something or we still don't have a preference for
"Show only tabs from the current container" as in issue #328 ?

I mean, we can hide groups, but there is no way of set the behavior of having just the tabs of the current container visible...

[klint]

@maverick74 you should give a try to the "Simple Tab Group" addon which provides tabs group management, panorama view and allows to link tab groups and containers (in both directions).
You can achieve what you are looking for with this addon:

• all tabs in a given group can open in a given container automatically
• all tabs opened in a given container can be moved to a given group automatically
• and as there are groups, only tabs within a group are displayed at a same time.

[maverick74]

@klint it's not the same thing ;)