Temporary-containers: [NOT AN ISSUE] Simple request

[EstherMoellman]

Hi @stoically ,

As you already saw here weeks ago, I'm in favor to have temporary containers (TC) as a Firefox' (FF) built-in feature. Sadly this is not happening yet, so I use to request some Devs to include the TC' API inside their add-ons.

But, why not to use your TC' add-on? This is because I don't ask Devs to replace your TC' add-on, but to replace just the simple TC' function: Automatically opening of every tab in a single TC.
The problem is that some Devs don't want or can't build TC inside their add-ons.

So I think now is time to go to the TC' Master... you!... TC' Yoda (LOL).
Please @stoically , can you consider the possibility of building a fork of your current TC' add-on? Here the idea will be a basic version with the following functions:
1) Automatically opening of every tab/link/etc in a single different TC.
2) Option at context menu, allowing to open tab/link/etc in new TC, same TC, no container etc (I believe this is already built in at Firefox).
3) Export/Import.
4) An option for Tab Manager add-ons (using tab hiding/discarding functions): "Refreshing" of all TC, every time FF' launches. This will need first to delete every existent TC when FF closes (while keeping tabs). And a new TC will be created for every tab, when FF launches. This will ensure that TC are really going to be destroyed at every FF' closing (specially for hiding/discarded tabs), always opening tabs in new TC at every new FF' session.

If you don't want to do that, or can't, or whatever, please can you check these alternatives below, and tell me which one is the best in your opinion?

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

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

Thank you in advance!

[stoically]

Hey,

Automatically opening of every tab/link/etc in a single different TC.

That's possible by configuring Automatic Mode and Isolation

Option at context menu, allowing to open tab/link/etc in new TC, same TC, no container etc (I believe this is already built in at Firefox).

TC already has a context menu (more options for that are planned in #342)

Export/Import

Exists

An option for Tab Manager add-ons (using tab hiding/discarding functions): "Refreshing" of all TC, every time FF' launches. This will need first to delete every existent TC when FF closes (while keeping tabs). And a new TC will be created for every tab, when FF launches. This will ensure that TC are really going to be destroyed at every FF' closing (specially for hiding/discarded tabs), always opening tabs in new TC at every new FF' session.

Add-ons can't hook into Firefox shutdown, so this would've to be done on Firefox startup. There could be an option that checks for existing tabs in TCs on startup and reopens them in a new TC; would you mind explaining how this feature would be useful and how that's related to tab managers? Personally I can't really see any advantage in that.

please can you check these alternatives below, and tell me which one is the best in your opinion?

I only briefly looked at them in the past, but I don't think they provide the features you were asking about.

[EstherMoellman]

Thanks @stoically for replaying.
I apologizes, per your answer seems I wasn't clear (perhaps due to my bad English). Please, allow me to rephrase my request:

I'm not requesting you new features.
And yeah, I know your current TC' add-on already has (most of) the features I described in my previous message.

What I requested you was a "new fork"... a simpler version of your current TC' add-on.
What I requested was a kind of "TC' lite version"... based on your current TC' add-on, but having only one function (I described in my previous message).
And the need for this "lite/tiny/lightweight TC' fork/version" (the need for my request) is based on the fact that your current TC' add-on is "too big, too complex, too sophisticated" for some users (like me). And here I mean that some users (like me) only want/need just one TC' function (I described in my previous message).
Also, a "lite version" of your current TC is needed as a complement for those add-ons, where their Devs can't (or don't want/know) build TC' functions inside their add-ons.
The two add-ons I attached you in my previous message, are a good example of what I requested you. Both add-ons have one simple function, and are very tiny when compared to your TC' add-on. I just wanted your own "TC' lite version", because in my opinion you're the most well prepared Dev in TC' field... you're the TC' Yoda (LOL). Also worth mentioning that a tiny TC' version probably will have less conflicts with other add-ons (or with FF itself).

But as I said, if you don't want to build a "lite TC' version", or you can't etc, I understand @stoically !, it's perfectly fine. In this case, I just ask you again your opinion about the two add-ons I attached you. I found at AMO only these two add-ons partially doing what I want. And if you can't attend my request building your TC' tiny version, then please at least will be great your recommendation for one of the two add-ons I attached you.

Now, with regards to my "4)" requested option: According to my ignorance, a TC only is cleaned (deleted) when the last tab (in this TC) is closed. But in this case, Tab Manager add-ons using "hiding/discarding" tab functions, almost never will delete a TC. And I'm not sure how this impacts in privacy, security or browser performance.
For example, I have STG. When I use TCs, with just few tabs my "profile\storage\default" grows several MBs. So, I assume lot of data is saved there (and this only happens when TCs are used). In the other hand, if I use a TC... is precisely because I don't want to keep this data. So, in my ideal world, I want the two functions:
a) I need STG in order to keep my groups and tabs.
b) But I want my TCs destroyed every time FF launches.

Thanks to your explanation, now I know add-ons can't hook into FF' shutdown. So, as you explained, perhaps what I want can be done at FF' startup?: At every new FF' session, every TC will be deleted, and every tab will be opened in a new TC. This is my "4)" requested option (I did in my previous message).
However, if for example you confirm me that those MBs in my "profile\storage\default" don't contain privacy/security/performance risks... then my "4)" option request might be unnecessary.

Sorry again if I wasn't enough clear in my previous message... I hope now I was able to explain myself better.
Thanks! : )

[stoically]

What I requested you was a "new fork"... a simpler version of your current TC' add-on.

I'm afraid I'm not interested in such a project.

too big, too complex, too sophisticated" for some users (like me)

If I can help clarifying certain aspects of TC I'd be happy to do that, just ask away. I know the current documentation is lacking and it has a steep learning curve, but I'm not exactly good in explaining, unfortunately.

Also, a "lite version" of your current TC is needed as a complement for those add-ons, where their Devs can't (or don't want/know) build TC' functions inside their add-ons.

The TC API currently exposes two endpoints, one to open a TC and one to check if a container is a TC. If another Add-on author needs more endpoints I'd be happy to add them.

probably will have less conflicts with other add-ons (or with FF itself).

That's unlikely. If automatic mode / isolation is built-in, it needs a fair bit of conflict handling.

hen please at least will be great your recommendation for one of the two add-ons I attached you

As I said, I only looked briefly at some other TC Add-ons; I'm happy other people work on that, but I can't recommend any since I'm only an user of TC.

For example, I have STG. When I use TCs, with just few tabs my "profile\storage\default" grows several MBs

There's still a bug in Firefox that prevents cleaning up the storage properly. It's fixed in Firefox version 73 (soon). See: #127. As said there, it doesn't impact privacy, because the storage isn't accessible anymore, since the containers pointing to that storage are already deleted.

b) But I want my TCs destroyed every time FF launches.

TC already deletes containers (by default) 15 minutes after the last tab in them closes and on startup for all containers that don't have any open tab belonging to them anymore.

Hope that helps.

[EstherMoellman]

@stoically ,

Your add-on is great! And your explanations are great too!
When I wrote "too big, too complex, too sophisticated"... I never meant "too difficult / too complicated". As I wrote, I only meant "too many functions for my needs"... that's all. So, I asked you just for a lite version of your TC. Again, nothing to change at your current TC' add-on, neither at your explanations etc... I just needed a simpler version of your TC' add-on. But you're not interested, so don't worry, keep your current excellent TC' add-on as it is now. Thank you anyway!

Now, again with regards to deleting storage, I still believe we are talking about different things. Your explanation applies to the case where the last tab in a TC is closed (and due to FF' bug, the storage is not cleaned). My case is different, I was talking about using the function of "hiding/discarding" tabs inside TCs... in this scenario, tabs usually never are closed (because are reused for months as hidden/discarded)... so, the TC also never is deleted. It's not a bug. It's just an undesirable consequence of hiding/discarding tabs inside TCs... and reusing those tabs in new FF' sessions.

You seem to said this is not a privacy/security/performance issue, so perhaps it will be better to forget what I'm describing.
However, if by chance you discover in the future, that hiding/discarding tabs inside TCs, tabs that never close (so TC never is deleted)... if this exposes privacy or creates security/performance issues etc, then in this hypothetical case, I believe my request is still valid also for your current TC' add-on. And my idea here is to delete every TC at FF' startup, creating a new TC for each hidden/discarded tab. At least, for those users using lot of hidden/discarded tabs, tabs that never are closed, you may offer to them the possibility of deleting all TCs at FF' startup, opening new TCs for same hidden/discarded tabs.

[stoically]

Thanks!

"hiding/discarding"

That depends how exactly the tabs are hidden. If the tab actually gets closed (no longer reachable by default Firefox UI) and the tab manager just remembers the URL to reopen if necessary, then the TC is regularly deleted. If the tab manager discards the tab by the means of the WebExtensions API, then the TC isn't deleted (tab is still reachable with default Firefox UI and its state is the same as when a session is restored after browser restart when restore tabs is active). Best course of action in that case would be using a tab manager that actually closes the tabs if you want the TCs to get deleted.

The default container counter (tmp123) reveals whether new TCs are created or not, so might want to keep an eye on that.

[EstherMoellman]

Best course of action in that case would be using a tab manager that actually closes the tabs if you want the TCs to get deleted.

... bingo!... that's the problem!
Sadly, and don't ask me "why?", after "hiding/discarding" APIs appeared, almost every Tab Manager add-on adopted it. Since them, I'm looking for a Dev interested in using "bookmarking/closing" tabs (instead "hiding/discarding"). However, it is not easy to find a Dev willing to build this new Tab Manager add-on. And the existent "Session-Saver" add-ons... they suck.

[stoically]

Oooh. After testing STG I realized that there's now a tabs.hide API which was introduced with Firefox 61, interesting. So _it is_ possible to hide without closing now, good to know. In that case TCs are not deleted, that's correct.

The problem here is that implementing something in TC that tries to reopen such hidden tabs would break the groups in the Add-on managing those tabs, since they rely on their own data. So while I could provide an option to reopen (delete & create) existing TCs on startup or with the click of button, it would most certainly break tab managers hopelessly.

I wonder, why not just use bookmarks for that use-case if you don't want tabs to actually exist? (bookmarks lets you open multiple tabs at once as well when right-clicking a folder)

[stoically]

So I checked, and something that could be done in TC is something that reopens tabs in a new TC when tabs switch their discarded or hidden status from true to false. Would that work for you?

[EstherMoellman]

... I'm glad to see you slowly but surely, arriving exactly to my same conclusions long time ago: "Bookmarking/Closing" tabs is many times much better than "Hiding/Discarding". And you can't imagine how much I "fought" against Devs, trying to convince them to use "Bookmarking/Closing" instead of "Hiding/Discarding". I even tried to convince the STG' Dev (a great guy!), to convert STG to "Bookmarking/Closing". But I failed! Devs in general are interested only in their own projects... and I don't blame them!

The problem with using bookmarks is that tabs are not automatically saved. So, if you want to replace a Tab Manager add-on using "Hiding/Discarding", you always will need a "Session-Manager" add-on. And as I wrote you, current "Session-Manager" add-ons are terrible bad. The few Tab Manager add-ons at AMO, using "Bookmarking/Closing", they're terrible too. In fact, most of these add-ons are totally abandoned because they're ugly, or unfriendly, or buggy, or etc.

Months ago I found a Dev (another great guy), which started to build a new Tab Manager based on "Bookmarking/Closing". However almost at the end, he stopped the process forced to attend his own personal life. His first prototype is here at GitHub, already 80% ready. I really hope one day he will finish this great add-on, or who knows, may be another Dev will be interested in finishing this add-on.

PS: Yeah, I welcome your "reopening of tabs in a new TC, when tabs switch their discarded or hidden status from true to false". It's not what I wanted, but it's an improvement considering actual situation. Thank you!

[stoically]

"Bookmarking/Closing" tabs is many times much better than "Hiding/Discarding"

Well, I can see why devs prefer native hiding/discarding using the webext API over a homegrown solution.

It's not what I wanted

Right, you said,

And my idea here is to delete every TC at FF' startup, creating a new TC for each hidden/discarded tab

Another possibility might be something that marks all existing TCs on FF startup as "outdated", and if a tab is activated (gets focused or switches discarded from true to false) that belongs to an "outdated" container, it gets reopened in a new TC (which automatically deletes the "outdated" TC as usual). That would prevent using any of the existing TCs after startup, without breaking tab manager groups. Would that match your idea?

However, if by chance you discover in the future, that hiding/discarding tabs inside TCs, tabs that never close (so TC never is deleted)... if this exposes privacy or creates security/performance issues etc, then in this hypothetical case, I believe my request is still valid also for your current TC' add-on.

Personally I'd say as long as you keep _tabs_ around (discarded, hidden, or in a "session manager") it's fine to keep them in their original TC. If one doesn't want to stay in the same TC, just close the tab. (I for one don't have "restore session" active, so the only tabs that survive restarts are pinned ones).

[EstherMoellman]

Personally I'd say as long as you keep _tabs_ around (discarded, hidden, or in a "session manager") it's fine to keep them in their original TC.

... yeap, probably as you said, this is not an issue at all. But at least is a kind of counter-intuitive issue, because a TC should be temporary. If we let a hidden/discarded tab inside TC, to eternally have the same TC (because the tab never is closed), then it will transform the TC in a kind of permanent container... loosing the function of temporary.
So, just as a matter of logic, I prefer temporary always temporary.
And if the user uses a hidden/discarded, with or without Tab Manager add-ons, if a user has a tab inside TC, and he reuses this same tab for weeks/months... then I prefer an option inside your TC add-on, offering the possibility of automatically opening these same hidden/discarded tabs in new TCs, at every new FF' startup. It will be a kind of "refreshing" TC, happening at every FF' startup. In simple words, under my definition, a TC never will survive more than one FF' session. This, seems to me, will keep the real "TC" meaning. In brief:
1) If user closes a tab inside a TC => The TC will be deleted
2) If user never closes a tab inside a TC => Your TC' add-on will offer two options:
2.1 Keep current tab in current TC
2.2 Keep tab (hidden/discarded) but automatically open this tab in a new TC (at every FF' startup)

If what I want is not doable/feasible at your TC' add-on, then any improvement from your side will be more than welcome, even if it is not 100% what I want.
Marking all existing TCs on FF startup as "outdated", and automatically replacing them with a totally new TC... at first glance seems perfect! IMO, this should not be related only to "hidden/discarded" tabs... it should be related to every TC at every FF' startup, replacing every "previous" TC with a "new" TC.

[stoically]

Opened https://github.com/stoically/temporary-containers/issues/363 accordingly.