Tab-session-manager: (Firefox) Multi-account container support

[Bert-Proesmans]

I'm using firefox containers to separate my workflows, like separate contexts. I think it provides a cleaner separation than using windows themselves.
For example, a separate container for social media, open-source development, learning Haskell, shopping for a product, general leisure/googling. Browser windows could hold tabs belonging to different contexts.

The exact problem I have is that I'd like to close all container tabs when I'm done with them for that day while preserving each tab state. The next time I open firefox with the purpose of quickly googling something I don't have to wait until all tabs/windows from the (entire) previous browsing session are restored.

Describe the solution you'd like
Is it possible to implement a 'firefox containers mode', which has the functionality to store and close a session of all tabs from a chosen container? Containers come with colors and icons so readability/session recognition could improve.

Describe alternatives you've considered
I tried to create my own extension, container-king, but I'm not keen on working in javascript. I also couldn't quite figure out how to support elegant/intuitive interactions with the extension.
I haven't found any other extension doing what I want ((ab)using containers as separate browser sessions). This extension looks nice and could probably provide that functionality.

Additional context
As I said I tried to implement my own extension at first. Meta things like how to properly interact with users, package the extension and a decent code pipeline are learned as I go.
I'd love to contribute to this extension, but I want to talk about the idea a bit more and get some guidance on best practices.

Edit: Does Chrome support personal containers, like firefox' multi-account containers, as well?

[1RonRock]

I'll bump this thread, maybe I should have started a new thread I'm not sure.

But my reason is that I would like to try out the FF Multi-Container addon. Before I do so I thought it best to ask if that addon is compatible with TSM? Will TSM work and support the container addon? Or will I be asking for trouble with TSM?

I would like to try it, but not at the chance that I will have trouble with TSM. TSM seems to be working very well for me currently. I love it and do not want to damage it.

[RobertAb1]

Similar issue: https://github.com/sienori/Tab-Session-Manager/issues/365

[Bert-Proesmans]

The intention behind this issue is a feature request to add another option to the current "save" button:

• Save all windows
• Save current window only
• Save current container

It's an alternative approach to storing sessions through grouping by container instead of a window. Actually closing all the saved tabs is a separate unresolved question.

[Bert-Proesmans]

Tab session manager and Tree style tab are powerful extensions, enabling powerful workflows.
I haven't thought deeply about how i'd like to use them lately, so this issue can be closed as being not focussed anymore.

[RobertAb1]

@Bert-Proesmans @1RonRock
There is Bug 1512802 (https://bugzilla.mozilla.org/show_bug.cgi?id=1512802) which was closed today (but it was stated that this bug can be reopened).
Please, describe there what Multi-account container support you need. Firefox developers could prepare proper APIs, so that session managers could use it.

[Bert-Proesmans]

Hi Robert,
Your comment on the bug item (https://bugzilla.mozilla.org/show_bug.cgi?id=1512802) explains exactly my original intentions for this issue. The items are clearly worded, which is a skill I admire a lot.
Hopefully, someone picks this up and attempts a PR.

Point 1 and 2 should be browser native behavior considering FF MA-containers is promoted as a first class feature (be it installable through the add-on system).
The third point could be implemented by extensions if no native support is put on schedule.
^ At least in my opinion.

[RobertAb1]

@Bert-Proesmans
I have updated my comment for Bug 1512802, mostly by adding point (4) and extending summary (similar to your comment). The proposal in the comment covers now broader set of functions.

Your description here is very nice too. You could just add your comment to Bug 1512802, maybe by combining what you wrote in your comment (2) + 2nd part of comment (4) + some background from comment (1) in this GitHub issue/post. Your comment would be very important and it could strengthen my proposal. Then, I will have the reason to reopen this bug.

[RobertAb1]

Thank you for your feedback on Bug 1512802. I have also re-opened this bug.

Can you also vote on session management API bugs listed on this page?

[RobertAb1]

@Bert-Proesmans
https://bugzilla.mozilla.org/show_bug.cgi?id=1298912

[Bert-Proesmans]

I gladly help you bring related feature requests to the top of "most requested", but that Reddit post looks overwhelming. I'm not currently in a mood to read every issue and vote. (I did vote on the last referenced issue, though)

[RobertAb1]

Bugzilla bug/GitHub issue
Consider supporting save/restore of individual containers within/from a session
https://bugzilla.mozilla.org/show_bug.cgi?id=1512802#c7
https://bugzilla.mozilla.org/show_bug.cgi?id=1512802#c8

[RobertAb1]

@Bert-Proesmans
Shorter voting list (it contains the most important bugs taken from longer list): https://github.com/sienori/Tab-Session-Manager/issues/364
Maybe this list will be better for you to view at the beginning :)

[RobertAb1]

I think that there is a small chance that Firefox will give us more advanced version of containers, since this could be complicated to introduce.
Maybe we need to get simpler proposal, but at the same time also useful for us; something that could replace tab groups and complement API to hide the tabstrip.

Maybe current concept of _sessions_ could be replaced by _session groups_ and _sessions_? _Session group_ could contain multiple _sessions_, and different _sessions_ (containing one or more windows) could be saved and opened independently. _Session_ could be marked by distinct color or icon (with short name) placed next to "List all tabs" (or in other place of windows belonging to particular session). _Session_ would contain information about windows and tabs (and their state - like today), and _session group_ would have information only about IDs of _sessions_ being a part of it (no information about windows and tabs). _Session_ would be corresponding to today's definition of _session_ (with small changes), and _session group_ would be completely new concept. Both _session groups_ and _sessions_ could be saved and restored automatically by Session Restore or session manager extension after Firefox restart; and both _session groups_, _sessions_ and windows could be saved manually by user.

And containers could operate as it is now; it would be user choice if (s)he wants to have tabs from single container included in single _session_ or not.

What is your take on this idea?

(EDITED)

[Bert-Proesmans]

I'm still considering the contents of a personalized container to be a sub-session of the "browser session". My view on, what you call, sessions is very narrow in that regard.
Sessions are sort of alive, you only work with the latest stored state, just like the "browser session" is implemented right now. There is room for extensions to snapshot/manage earlier state of sessions, for example.

Your (original) comment reads like you're thinking about merging the session idea with browser windows. I disagree with that direction since this practically mimics built-in user profiles for the browser.
Sessions should _only_ contain tab URL, history, page state, cache, .. (= tab data). The "browser session" keeps track of which tab was located in which window at which position (= tab metadata). The session functionality stays focussed and highly flexible this way, in my opinion.

I'm unsure if i can contribute meaningfully with UX design of this feature due to lack of experience. I don't how other browsers tackled similar issues or have a general idea about what would work best.

I see you edited your post with a different explanation (from first glance). I'll be coming back to this issue tomorrow (CET here) and respond to these changes.

EDIT Changed terminology

[RobertAb1]

I see you edited your post with a different explanation (from first glance). I'll be coming back to this issue tomorrow (CET here) and respond to these changes.

The original names I used were: _sessions_ and _subsessions_
New terminology: _session groups_ and _sessions_

[RobertAb1]

@Bert-Proesmans
The relation between _session_ and _tab_ would be the same like now. Just additional level above _session_ called _session group_.
_Session group_ would something lower than profile (for users who do not want to use profiles). Different profiles can have different set of extensions and browser settings, but also opening different Firefox profiles at the same time is using a lot of resources.

[Bert-Proesmans]

You reworded your original comment and a first glance it looked to be a different proposition, but it's basically the same as before with a new keyword attached on top of it.

For starters, I don't understand which workflows can be enabled by supporting session groups. The way I see it, FF containers already perform user profile emulation by isolating history and cached data (at least in theory). Which workflows would an additional group level enable?
Please work out an hiërarchical tree of sessions- and groups as an example, I'll understand it better that way.
My position on this is that there should only be one session group, which is rooted at the profile level aka the current "browser session".

I feel like I'm going to repeat myself since I'm interpreting the updated text just like the old one so I'll try to keep this response very short.

Browsing sessions are currently groupable by the window through the use of extensions. Browsing sessions should also be groupable by privacy horizon. This could abstract into a 'session'.
A user ideally becomes free to construct a new session from the result of whatever grouping condition he wants. No grouping by window should happen without the user allowing it, because it's perfectly possible for tabs to be scattered around multiple windows which each contain tabs from other sessions.
The user should get the ability to one-click open/close sessions, meaning all tabs belonging to that session will be opened/closed while their state is preserved. We both agree the last point is a necessity.

[RobertAb1]

(UPDATED PROPOSAL)

I think that there is a small chance that Firefox will give us more advanced version of containers, since this could be complicated to introduce.
Maybe we need to get simpler proposal, but at the same time also useful for us; something that could replace tab groups and complement API to hide the tabstrip.

(1)
Current concept of sessions could be replaced by _session groups_ and _sessions_. _Session group_ could contain multiple _sessions_. _Session_ (containing one or more browser windows) would contain information about windows and tabs (and their state - like today), and _session group_ would have information only about IDs of _sessions_ being a part of it (no information about windows and tabs). _Session_ would be corresponding to today's definition of session (with small changes), and _session group_ would be completely new concept. Firefox or its extension should remember names (given by user) of opened _session group_ and _sessions_ (and use these names during automatic savings of _session group_ or _session_ together with information about time of saving; or suggest these names during manual saving of _session group_ or _session_).

Different _sessions_ could be saved and opened independently from _session groups_. Both _session groups_ and _sessions_ could be saved and restored automatically by Session Restore or session manager extension after Firefox restart (multiple previous saved versions should be remember, not just the last version). And both _session groups_ and _sessions_ could be saved manually by user; manual saving could be done for single _session group_ or _session_ at the time. Finally and most importantly, sessions could be added or removed from current session group; and the names of opened session group and sessions should be remembered by Firefox/extension, and these names should be suggested by Firefox/its extension during manual saving of session group or session.

(2)
Firefox windows belonging to particular _session_ could be marked by distinct color or icon (with short name) placed next to "List all tabs" (or in other place of windows belonging to particular session), and taskbar buttons corresponding to Firefox windows from the same _session_ could be marked by the same color.

(3)
And containers could operate as it is now with multiple containers in single _session_.
In addition, it should be possible to assign different sessions to separate containers, and to make all tabs opened in particular session a part of specific container.

[RobertAb1]

Simple example of new workflow possible after _session group_ introduction is shown below and it consists the following actions:

• adding sessions with multiple windows,
• adding new windows to particular session,
• closing entire sessions,
• closing/saving session groups, and
• opening other session groups.

group1[A(A1,A2,A3)]
group1[A(A1,A2,A3),B(B1),C(C1,C2,C3)]
group1[A(A1,A2,A3),B(B1),C(C1,C2,C3),D(D1,D2)]
group1[A(A1,A2,A3),B(B1),C(C1,C2,C3,C4,C5),D(D1,D2)]
group1[C(C1,C2,C3,C4,C5)]
group2[E(E1),F(F1,F2)]
group2[E(E1),F(F1,F2),D(D1,D2)]

Firefox should remember which windows belongs to particular session, and names of session group and sessions. Closing of chosen session should cause also closing of windows being a part of particular session.

Description:
group1[], group2[], ... - session groups
A(), B(), C(), D(), ... - are example sessions which could correspond to: A - work, B - things to do; C - interests; D - other activities
A1, A2, A3 are example windows in session A

[Bert-Proesmans]

It's hard to effectively follow what exactly has changed in your edited comments. 10 days ago is also the culprit of me not being able to remember previous details.

I'm personally on the fence about your latest proposal and example. The feature (do you consider the whole as one or more features?) is too complex, judging by your description.
What would be use cases of having such flexible session groups? Since it's new, the concept on itself introduces a new mental burden and implementation complexity. Use cases should be strongly defined and well-grounded because otherwise, you risk annoying your user at best.

[RobertAb1]

The main point is that _session groups_ are added (point (1)).

The major benefit is that _sessions_ could be added or removed from current _session group_; and the names of opened _session group_ and _sessions_ should be remembered by Firefox/extension, and these names should be suggested by Firefox/its extension during manual saving of _session group_ or _session_.
Example is just showing what this new future could provide us.

Points (2) and (3: containers) are separate (but related) issues, which can be fixed after adding session groups.

[JohnLGalt]

TBH, although I have been talking with Robert for a long time now about various things, I have to admit one solid thing:

_This_ issue is about enabling SM support for Containers. Everything that Robert is suggesting is more of a general _massive_ upgrade to the whole native session manager in Quantum.

I can see both sides. On the _One_ hand, many people are going to say "Just add container support and be done with it - that's all I want." And I suspect that this is the way that the Fx dev team is probably going to go.

OTOtherH, though, I can quite easily see how Robert's proposed overhaul of the native SM in Quantum would make it that much better versus what we have now.

To me, Robert's ideas are more akin to the original SM for Fx <57 (the one from MozDev that we all knew and loved and used for many years), whereas just the simple inclusion of containers in the current SM native to Quantum builds would be akin to the original addition of the SM into Fx builds so many years ago - simple, does what it says and gives you just that little bit of piece of mind in case your session goes wonky while you're using it.

It's better than having no backup at all - but what if the session goes wonky as it is being backed up? Then, you're SOL.

I truly believe that we need much more than a simple SM as is now implemented in Quantum builds. I can clearly follow Roberts' logic and workflow on what he is describing, and for the most part I could see it working. But, TBH, the best of all worlds, to me, would be to include all of the functionality of SM from MozDev + complete support for Containers (IOW, making the SM interface container-aware - so if you go to save a single tab into a session store (any session store you choose) it will also save container information that will later be restored.

The biggest issue I see here is if the Session store has container information for one or more tabs, and it is restored onto a profile that does not have that container (or does not have containers even enabled) - that would mean that the interface would have to be even more aware of the current profile as well as the Session store, in terms of what is stored, and have to warn the user the the container for one or more tabs does not exist, (and would then either have to create said container, restore the tab without any container specific info, or just ignore, or not restore the tab), or else throw no warning up at all, perform a pre-defined action (say, ignore the tab(s) in question, or just restore them into the base 'container'), which could cause all sorts of issues if 2 tabs to the same site with different logins (and thus different containers) are loaded into the same base container, no? Just that scenario _alone_ will cause massive headaches unless it is thoroughly planned for prior to the implementation of container support in SM.

So, IMO, Adding Session groups doesn't help this at all - the complete (or nearly complete) feature set of the old SM from MozDev + Container awareness and support is more, probably, of what the OP here was asking for. I say this because, as I have outlined with a single scenario, simple container support for the existing SM in quantum builds is going to cause too many issue sin and of itself without some serious pre-planning (and, even better, some serious coding to allow the user to control how scenarios such as the one I outlined above are actually handled - with a STRONG EMPHASIS from me to make sure to allow the user to manually handle the situation (which is my biggest pet peeve - software that assumes you will always want to perform a certain action given similar circumstances).

SO, to Fx devs - research (and ask _us_, the actual users of Containers) on how best to implement Container support in the existing Quantum builds. Everything that Robert suggest I would recommend for an addon developer to develop in much the same way that SM was originally developed for Fx.

However, I have to admit, I suspect that the complexities of making the Session Manager container aware may make them push the entire idea onto a 3rd part addon developer.

Sorry for the long post - but those are my thoughts.

[Bert-Proesmans]

Your interpretation of the discussion in this issue aligns with mine.
I want to make clear that the functionality I asked for is not based on previous browser behavior, because I haven't used Firefox much before the Quantum release. It's based on what is intuitive behavior (for me) and any correlation is incidental. I'm also not entirely sure what _exact_ functionality+behaviour is referred to with include all of the functionality of SM from MozDev + complete support for Containers (IOW, making the SM interface container-aware

Session data going wonky during backup is something I have seen reported a few times. I think mitigation functionality should be implemented above (outside) the current SM component, but more on that below. The current SM component is not effectively managing anything.

I have currently no opinion about the concepts Robert described. I consider myself not an advanced enough user to decide if implementing this will lead to a positive or negative outcome.

Regarding the issues you noted; That's (indeed) why I'm thinking about adding session awareness to the container component instead of the other way around. Each container will become equivalent to a session.
This is pure feature addition and composes neatly into the current SM system.
Net result becomes; one session group, aka the browser session, containing each container session.

Roberts concept can be implemented as a next step, by introducing namespacing into the SM. This enables the transition into multiple session groups.
With an SM effectively taking on the role of actually managing session (groups), it becomes logically sound to implement backup strategies, and other related managing tasks, directly into the SM component.

[RobertAb1]

(1)

Session data going wonky during backup is something I have seen reported a few times. I think mitigation functionality should be implemented above (outside) the current SM component, but more on that below. The current SM component is not effectively managing anything.

We have not yet fixed bug 1298912, which could be incorporated into solution here. Also my proposal does not make sense without the capacity to recover earlier sessions, so it is important part of the proposal. Bug 1235231 is also crucial here.

.

(2)

The work on session restore component probably needs to be done first, since some work here already started. See especially dependency tree of bug 1474130 and bug 1517895, and to less extend bug 1423917, bug 944918 and bug 1482662. The work on session management API will be next. So it is good time to mention about this now. Later it could be too late.

[JohnLGalt]

Your interpretation of the discussion in this issue aligns with mine.
I want to make clear that the functionality I asked for is not based on previous browser behavior, because I haven't used Firefox much before the Quantum release. It's based on what is intuitive behavior (for me) and any correlation is incidental. I'm also not entirely sure what _exact_ functionality+behaviour is referred to with include all of the functionality of SM from MozDev + complete support for Containers (IOW, making the SM interface container-aware

Session data going wonky during backup is something I have seen reported a few times. I think mitigation functionality should be implemented above (outside) the current SM component, but more on that below. The current SM component is not effectively managing anything.

I have currently no opinion about the concepts Robert described. I consider myself not an advanced enough user to decide if implementing this will lead to a positive or negative outcome.

Regarding the issues you noted; That's (indeed) why I'm thinking about adding session awareness to the container component instead of the other way around. Each container will become equivalent to a session.
This is pure feature addition and composes neatly into the current SM system.
Net result becomes; one session group, aka the browser session, containing each container session.

Roberts concept can be implemented as a next step, by introducing namespacing into the SM. This enables the transition into multiple session groups.
With an SM effectively taking on the role of actually managing session (groups), it becomes logically sound to implement backup strategies, and other related managing tasks, directly into the SM component.

My apologies - I had no idea on your previous Fx usage and experience. I suppose that, in and of itself, negates my assumption of the use of SM (shortcut for Session manager), and addon that a lot of people used to bolster the native Session Manager built into Firefox pre-Quantum builds.

Today's computers are much, much faster than when I first started using Phoenix 0.4 (or 0.7 one of those), which was the original builds of Firefox, pre version 1.0 (yeah, that was a while ago). Back then, saving your session almost always involved saving the data to a particularly slow mechanical HDD, which meant it could take upwards of a second or longer - plenty of time for the data to get corrupted if the process was interrupted (by a crash, for instance). I can't count without going into triple digits how many times I lost a session because of something that went screwy somewhere somehow. As my systems started getting more and more up to date, and as Firefox became a better and better browser, those instances started happening more infrequently. But they have still happened, more often than I would like for them.

In that respect, yes, the native Session Backup & Restore mechanism (which I call, for lack of a better name, Session Manager) does leave a lot to be desired. But even when it was first added to Firefox builds, oh so many years ago, it basically did nothing more than it does now - provide for a restore of your previous browsing session into your current session. It was only as good as the backup itself - if the session backup is corrupted, uh oh.

The SM addon that is still available from MozDev (that is a site, not the developer), but only works on pre-Quantum builds of Firefox and Fx-based browsers, _enhanced_ the native SM of Firefox by allowing the user to make multiple backups of (different or the same) session, allowed the user to name them, had a lot of functionality in terms of automatically naming sessions (default was time and date, IIRC), and also allowed the user to choose which session to restore - in effect, extended the capabilities of Fx far beyond what was available. In fact, that addon helped a lot of users use Fx as their go to browser for both home and work (especially after Mozilla's Weave service, which we now call Firefox Sync, came into play) - when you open at work, restore your work session, and save when you close, then when you come home, open your home session and run with it. You really did not have a major need to make multiple profiles anymore (although that was still the 'officially supported' method versus using the SM addon).

One thing that SM (and Fx in general) do not allow the user to do was handle using multiple, discrete logins to the same website _simultaneously_, and that is where the Test Pilot project of Multi-Account Containers comes into play. Containers were added a while back to Fx, but the Addon (Available from AMO) called Multi-Account Containers vastly extends the capabilities of the default, native Containers. If you consider them side by side, the SM addon for pre-Quantum Fx is to the native SM in those builds as MAC (Multi-Account Containers) is to the native Containers.

IOW, Fx has, for a very long time, included only basic functionality when it came to the native SM. I don't see that changing much. However, I DO see then (hopefully soon) incorporating, at the very least, the native Containers, in their backups (and they very well might already do so - I've been using MAC for a very long time now, as well...).

My guess, though, is that anything above that (including support for MAC addon) will need to come from a 3rd party developer.

[JohnLGalt]

(1)

Session data going wonky during backup is something I have seen reported a few times. I think mitigation functionality should be implemented above (outside) the current SM component, but more on that below. The current SM component is not effectively managing anything.

We have not yet fixed bug 1298912, which could be incorporated into solution here. Also my proposal does not make sense without the capacity to recover earlier sessions, so it is important part of the proposal. Bug 1235231 is also crucial here.

.

(2)

The work on session restore component probably needs to be done first, since some work here already started. See especially dependency tree of bug 1474130 and bug 1517895, and to less extend bug 1423917, bug 944918 and bug 1482662. The work on session management API will be next. So it is good time to mention about this now. Later it could be too late.

Yes, I have to agree, bug 1298912 is a must have, and would go a long way to satisfying the the multiple-named backups (I assume it would be time stamps again) and allow the user to restore from a crashed session, *even if it crashed during the backup-making process, as long as there is even one other backup already previously made.

As for the differentiation between the SM component and the SM API, you're spot on - once that API is developed, hopefully someone can step up and make a new, modern SM for Quantum builds.

[RobertAb1]

I have created the following bugs related to session groups and containers in session groups:
Bug 1524948 (session groups) (please, check comments 1-6)
Bug 1524955 (marking sessions by distinct color)
Bug 1524959 (assigning different sessions to separate containers)

[RobertAb1]

I have filed bug 1528598 ("Allow Firefox/session managers to manage multiple sessions at the same time") - simplified version of bug 1524948.

Recently, bug 1524948 was moved from WebExtensions to Session Restore (https://bugzilla.mozilla.org/show_bug.cgi?id=1524948#c9) (the same applies to bug 1528598).
Thus, I had to file additional bug 1528604 to get WE API, so session manager extensions would be able to support this future through API.

Now we have the following bugs describing proposals about multiple sessions and containers (two first bugs are new):
https://bugzilla.mozilla.org/show_bug.cgi?id=1528604 ! (NEW: Feb 17, 2019) -new bug on the list
https://bugzilla.mozilla.org/show_bug.cgi?id=1528598 ! (NEW: Feb 17, 2019) -new bug on the list
https://bugzilla.mozilla.org/show_bug.cgi?id=1524948 ! (NEW: Feb 4, 2019)
https://bugzilla.mozilla.org/show_bug.cgi?id=1524955 (NEW: Feb 4, 2019)
https://bugzilla.mozilla.org/show_bug.cgi?id=1524959 (NEW: Feb 4, 2019)
https://bugzilla.mozilla.org/show_bug.cgi?id=1512802 (NEW: Dec 8, 2018)

[RobertAb1]

SESSION MANAGEMENT AND CONTAINERS:

(1)
Consider assigning different sessions to separate containers (multiple sessions and containers)
https://bugzilla.mozilla.org/show_bug.cgi?id=1524959
https://bugzilla.mozilla.org/show_bug.cgi?id=1528598#c6
https://bugzilla.mozilla.org/show_bug.cgi?id=1528604#c2

(2)
Consider allowing individual session management of containers
https://bugzilla.mozilla.org/show_bug.cgi?id=1512802

Consider supporting save/restore of individual containers within/from a session (GitHub)
https://github.com/mozilla/multi-account-containers/issues/1325

[JohnLGalt]

Going back to the original issue mentioned, I would like to see MAC have this as well.

Right now, when I open Fx and it has tabs already loaded (because of my setting to restore tabs from the previous session) it loads the tabs exactly as they were when I closed Fx - IOW, from cache. This is great, for multiple reasons:

1. I don't have a bunch of tabs trying to restore simultaneously (even with a 300+ Mbit (downstream) connection, it takes a bit of time);

2. I'm at the exact place I was before when I closed my previous session - which is exactly where I want to be in certain scenarios, and if I want to refresh I can do it manually.

With MAC, this does NOT happen - I open a container, say, one that has 8 tabs - immediately all 8 tabs start refreshing, as if I have load from cache disabled.

That one little setting would satisfy most users - those that want loading from cache (enabled) and those that want loading live (as it works now, so _disabled_).