Request: Support to temporary containers

[EstherMoellman]

@jingyu9575 ,

When users have temporary containers (tc) at STG/PT or similar add-ons using "hiding/discarding", tc become permanent containers (I discussed this days ago with @stoically, TemporaryContainers ' Dev). Those tc almost never are deleted (only when a tab is deleted). So they keep accumulating and accumulating inside add-on storage. This may generate performance issues and conflicts with other add-ons or with FF itself. Not to mention that a tc should always be temporary, deleting itself when FF closes.

Now, when users have your add-on and tc, finally tc are really temporary, because as you know, each time a group is changed in your add-on, tabs are closed, and tc are deleted. However, an user may request to keep his tc until FF closes. And again, your add-on closes tabs every time a group is changed. The ideal here will be to keep tc alive until FF closes.

Well my friend, this is a challenge, because I don't know if this is doable in your add-on. But you're a genius (LOL), and who knows, perhaps you can find a workaround. In brief, the ideal will be to have an option at your add-on, allowing to keep tc per FF' session, not changing when groups are changed.

What are your thoughts?

PS: Even if a permanent container is used, your add-on seems to delete the container when a group is changed (tab closed). This forces users to login again and again their webpages, each time a group is changed.

[jingyu9575]

This is going to be complicated. Let's think about permanent containers first:

• Suppose the user opens gmail.com in the Google container. The user switches to another group and then switch back.
• Current behavior: the website opens in the default container.
• Desired behavior: the website opens in the Google container.
• So the extension has to save the container name for every saved tab. Probably in the extension storage, because bookmarks cannot store container names.

Now we are in the same situation as the favicon issue. Both need to be in the extension storage. Any thoughts on it?

[EstherMoellman]

ha ha ha lol... I knew this was going to be a complicated one lol : )

Well, the first question here always will be if it is possible to do something for favicons/containers, without using add-on storage. It will great to find a workaround using just bookmarks. If you want, I may try to consult other Devs about this possibility. I also have 2 or 3 great contacts at FF. But if you already have the knowledge, and you already know this is not doable with bookmarks, then we must jump to the next question:

What is better? To store favicons/containers at add-on storage? Or to live without favicons and with containers changing every time a group changes?

I personally can perfectly live without favicons and using changing containers. But most of the users will request favicons and unchanging containers.

I hope you'll find a workaround using just bookmarks. But if it is not doable, don't worry, it's not the end of the world, let's see how terrible is to keep favicons/containers at add-on storage. Perhaps we discover that favicons/containers at add-on storage has not negative impact.

PS: By the way, the general browser performance is much better with your add-on (compared to STG/PT or similar add-ons using "hiding/discarding"). The browser feels much more responsive, lightweight, everything behaves faster etc. No doubt, it's a general browser performance improvement. For me there is no way back to "hiding/discarding".

[stoically]

My current workaround (until FF supports it natively) to bookmark websites in permanent containers is using the Open URL in container Add-on, though, since that needs to store the URL in the format ext+container:name=Container Name&url=https://example.org it might not be suitable here.

As for keeping temporary containers until restart - I could offer an API to not delete TCs until after restart, if that helps, let me know.

[EstherMoellman]

@stoically , how nice to see you here, thank you for your collaboration, your help always will be more than welcome!

@jingyu9575 , hope you can take advantage from @stoically ' suggestions, but if they can't be applied to your TTBG, and if you still don't have a better solution of yours... I found another add-on (ContainerBookmarks), based on this comment and this another comment.

This add-on I found is not exactly what we need for your TTBG' add-on. But I wanted to share with you, because it seems this add-on works at bookmarks level, no add-on storage (apologies in advance if I'm wrong). It seems this add-on ads some identification directly inside bookmarks, allowing bookmarks always to open in a specific container. This add-on is open source, so perhaps you can steal some ideas from it.

If by chance this add-on somehow works for your add-on, in the worst case we can use a temporary container add-on in order to open any non-specified bookmark into tc, and when user needs to keep the same container, we can use this ContainerBookmarks add-on to always open specific bookmark in specific container. In other words: Every bookmark will be opened in TC, until user specifies a bookmark to open always in same container.

Yeah, I know this might not be the solution we're looking for, but as I said, perhaps you can pick few ideas from here and there, and at the end these ideas may help you to find a workaround.

[jingyu9575]

@stoically

store the URL in the format

Yes this is a workaround but the URL is changed, preventing copying and editing. I can think of several workarounds with bookmarks with different caveats, but IMO none is perfect.

I'm still not sure about the stability of extension storage. I haven't seen any extension storage corruptions except for a Firefox 72 bug. Have you seen such corruptions, and what parts (browser.storage.local, localStorage, indexedDB) are affected?

not delete TCs until after restart

I haven't read the code thoroughly but it seems that temporary containers will be cleared on both timeout and restart. Do you think it is enough to simply add a option Infinity to containerRemoval?

[jingyu9575]

@EstherMoellman

So these are the workarounds I can think of, and their trade-offs.

1. Change the URL to a special format e.g ext+ttbg:name=...&url=.... This is @stoically's suggestion.

   • Bookmark URL is changed. User cannot copy or edit them.
   • Large Favicon must be resized to thumbnails, because Firefox limits bookmarks to 65536 characters.
   • Firefox periodically backups the bookmarks, and I'm not sure if long URLs have negative effects on stability and performance.

2. Append the data to the URL e.g. http://example.com/#the-container-and-favicon-data. This is ContainerBookmarks's approach.

   • User can copy or edit the URL, but depending on the website, copied URL may not work outside the extension.
   • The URL will be very long with favicons, making it difficult to copy and edit.
   • Firefox periodically backups the bookmarks, and I'm not sure if long URLs have negative effects on stability and performance.

3. Prepend the container name to the bookmark title. This is what we use for the active/pinned status.

   Group 1
   📌︎ ⟦Google⟧ Gmail
   ▶︎ ⟦GitHub⟧ jingyu9575/tabs-to-bookmark-groups - GitHub.com
   ⟦⏲⟧ A site in temporary container
   A site not in any container

   • I think this is a clean approach to save container without tampering the URL, and the user can easily see or change the container, but:
   • Not applicable to favicons
   • If there is a small chance that the website title already has ⟦⟧, it needs to be changed.

4. Add a Metadata bookmark folder in the TTBG folder, and save everything as bookmarks in it. Basically, we reimplement extension storage as a list of bookmarks.

   • Lots of work and development time
   • There will be an extra annoying folder
   • If user removes or changes this folder, the storage will be gone
   • Firefox periodically backups the bookmarks, and I'm not sure if long URLs have negative effects on stability and performance.

5. Just use extension storage. No more workarounds and annoying bookmark changes, but:

   • May corrupt (how often? what exactly is corrupted?)

[stoically]

I'm still not sure about the stability of extension storage.

Personally I've only used browser.storage.local, and had some experiences of storage loss when my machine completely froze - but it only affected the TC add-on, so it might very well have been bad practice on my end. Refactored some of the storage code and didn't happen since (FF version ~65 or something, I think). Seems to match TC users experiences. Also, providing something to export&import storage to recover from data loss seems useful anyway.

Do you think it is enough to simply add a option Infinity to containerRemoval?

Yeah, that should work (there's an open issue to provide such an option). The API idea was more because it might allow cleaning up "normal" TCs as usual, and only keep "hidden in bookmark" containers around.

[EstherMoellman]

Hi @jingyu9575 ! Thank you for such nice effort you are doing.

Firstly I want to say, yeah, now is clear that lot of requests need add-on storage. And I can see you are totally capable of literally break your head, working tons of hours, and ending with a workaround for every request being implemented without add-on storage. But honestly, this starts to seem to me very traumatic for you, it will make TTBG' development too much time consuming. And in the future users may request more and more features, and without add-on storage this always is going to be a limitation for you as a Dev.

So in this context, and also based on last @stoically ' answer... what do you think about OPTION 05: To build a storage for TTGB? Questions: a) To build a TTGB' storage will make your life easier as a Dev, for example with favicons, containers, icon group colors etc? What are the pros of having a storage? b) What about FF' bookmark editor functions? With an add-on storage, it will possible to use FF' editor? (copy, paste, import, export etc) c) Is it possible to build a kind of minimalist storage? (in order to avoid potential issues, corruption, conflicts etc)

If by chance you still want to give a chance to the "no add-on storage" alternatives, here are my answers to the other options you offered:

OPTION 01: Hmmm... user cannot edit/copy etc... this may be rejected by users in the future.

OPTION 02: Based on my ignorance... I liked this option! Question: The only cons I see here, is the potential dependency with the add-on (this is not really clear to me). Is the add-on needed for this option? Or do you plan to include its code inside TTBG? And what about the tc behavior? How exactly is this going to work? The ideal behavior is to have a tab with tc, but the tc survives only the current FF' session, when FF closes all tc are deleted, and new tc are created when FF launches again. Is this possible with this "option 02"? If this option 02, somehow, can be independent from the add-on, well, then seems we can have both: favicons and tc. Again, I don't really see as very negative "long urls" etc, and currently TTBG always takes few milliseconds to change to new groups, so I doubt it will take much more milliseconds to save long urls.

OPTION 03: If I well understood you, this option seems pretty nice. I believe the icon ⏲ alone will be enough (there is no need for ⟦⟧). Question: Same question "option 02" above, about "tc ideal behavior". If "option 03" is not applicable to favicons, do you have another workaround for favicons? Or let's forget about favicons?

OPTION 04: Hmmm... seems a no go.

[jingyu9575]

@stoically Thank you.

Refactored some of the storage code and didn't happen since ... Seems to match TC users experiences

I agree. I have a download manager extension that uses all kinds of storage heavily (up to several GB), and I think storage corruption is also very rare among its users.

The API idea was ... only keep "hidden in bookmark" containers around.

I see. Looks like an API is the better way. Thank you, I can add support if the API is developed. I think I also need a function to release a container lock, if the relevant bookmarks have been deleted by the user.

[jingyu9575]

@EstherMoellman

What are the pros of having a storage?

It is easier, but other workarounds are not difficult either. The major advantage of extension storage is they do not affect things visiable to the user. If the favicon is in the storage, the user won't see them and won't be bothered with them in any way.

If the favicon is stored in the bookmark with option 2, the URL change is visible to the user. When the user want to send a GitHub link to a friend, they copy the bookmark to WhatsApp, and instead of https://github.com/ they see this:

https://github.com/#TTBG-favicon=data:image/x-icon;base64,AAA
BAAIAEBAAAAEAIAAoBQAAJgAAACAgAAABACAAKBQAAE4FAAAoAAAAEAAAACAA
AAABACAAAAAAAAAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
BERE3YTExPFDg4OEg (8000+ characters omitted)

You see the problem?

With an add-on storage, it will possible to use FF' editor?

There is an editor in about:debugger but I don't think users will use it.

So I think it may be better to divide the information into important and secondary parts. The tab title, URL, pinned status are important and saved in the bookmarks (already done). The container name should also be important for privacy reasons, and we can use option 3 for that:

Bookmark title:   📌︎ ⟦Container name⟧ Tab title
Bookmark URL:     Website URL

Then we throw the favicons into secondary extension storages. If they corrupts, only the icons are lost, and they will be refreshed when the group is saved again.

In my opinion this is the best option considering the trade-offs.

[EstherMoellman]

A-M-A-Z-I-N-G!... how nice to see so much progress... beautiful... thank you!... and congrats, really very nice job.

And you chose the right logic! If I understood you, when possible, you're going to develop features directly inside bookmarks. And if not possible, you're going to use a simple add-on storage. As you said, "important" stuff is going to be at bookmarks place. And "secondary" stuff, to storage. If storage gets corrupted, only secondary stuff is lost, everything important always will be backuped at bookmarks. Yeah, definitely seems the best logic! Claps to you! Attached below the results of my tests:

PERFECT:

• Close icon popup.
• Options page.
• Dark theme: Icon popup + Sidebar + Options page.
• Favicons.
• SideBar support.
• Icon color: Let me see if I understood you... at bookmarks, a colored circle will appear (let's say red for Group 1)... and at NavBar/ToolBar/etc, when Group 1 is selected, the icon will be red. If this is your idea, then is a PERFECT idea! For me to make icon colored is enough (from user info functional point of view), but I don't have issues with colored circles at bookmarks.
• FF' bookmarks editor: I must apologies, I used the wrong term, I meant "Library" function (control + shift + H). And is working perfect!

NOT SO PERFECT:

• When a group is changed, all tabs seem to be loaded for a 1/2 second, and only then all tabs become unloaded. If you have few tabs in the group, this not an issue at all. But if you have 50 or more tabs in a group, it's kind of heavy, everything is started to load and before loading everything is unloaded.
• When a tab is selected, it has a kind of "grey flash"... it is a kind of grey blink, same grey than options page. And sometimes it is possible to see that an internal page is loaded in the background before the tab content is loaded. I wont call this a "performance issue"... performance seems fine (everything passes very fast)... the problem is that the grey blink and the page loaded before tab content, both are quit visible.
• At SideBar, when TTBG is selected at SideBar header menu, is not possible to see tabs inside groups. Users only can click over a group, changing groups. But is not possible to see tabs, or to choose a tab etc.

I hope I covered everything. Please tell me if I forgot something.

[jingyu9575]

Today I tried this, and it seems to be more difficult than I thought. The extension has to store the containers' hidden id instead of their name, because there can be duplicate names. So I think we have to use extension storage for containers, becauses the id does not look good in bookmark titles.

[EstherMoellman]

Hi @jingyu9575 !

It's totally fine, don't break your head, go with extension storage. You tried, you invested lot of efforts and every-time a new feature/idea appears it seems to require extension storage. So, I believe is time to start using extension storage.

And yeah, of course "no extension storage" was a nice bonus or plus. But I don't believe this is the end of the world. The main function of TTBG is: a) Bookmarking b) Closing c) Grouping. And all the rest, including extension storage, are merely bonuses, additional values etc.

Also, extension storage will allow you in the future to easily incorporate new features.

For me Temporary Containers are a must. Today I use TTBG with pinned tabs, because is the only way my Temporary Containers are not deleted every-time I change a group. So yeah, it's time, extension storage will be more than welcome for me, allowing the normal use of Temporary Containers.

By the way, if you start using extension storage, perhaps you can improve favicons at unloaded tabs? (https://github.com/jingyu9575/tabs-to-bookmark-groups/issues/11). It seems you want to use extension storage only for Temporary Containers. But I wonder if it is not better to use extension storage extension for all tabs, for example improving favicons and other features. Well, is your call, you have the final word.

Just as a reminder, another pending requests are: 1) Icon at NavBar/ToolBar changing color identifying group (https://github.com/jingyu9575/tabs-to-bookmark-groups/issues/8). 2) ContextMenu (tab, sidebar, icon popup etc) allowing to move tabs to different groups (https://github.com/jingyu9575/tabs-to-bookmark-groups/issues/13). 3) SideBar expanding/collapsing groups (https://github.com/jingyu9575/tabs-to-bookmark-groups/issues/10).

I hope these requests and other future requests will be easier to implement by having extension storage. I hope extension storage will make easier your life, maintenance and creation of new features.

[jingyu9575]

Permanent containers are now supported, and tabs will be reopened in the same container when they were saved.

Temporary Containers are not deleted everytime I change a group

This requires new API in the Temporary Containers extension. You can now workaround it by opening the Temporary Containers options, press F12 and run the following code in the developer tools' Console tab. This will set the option Delete no longer needed Temporary Containers to 24 days, so practically they will only be deleted on browser restart.

p=(await browser.storage.local.get('preferences')).preferences; p.container.removal=2147483647; await browser.storage.local.set({preferences:p})

Additionally, if the temporary container is deleted, my extension will restore the tabs into the default container instead. I think the expected behavior is to restore into a new temporary container, but this also requires API changes in the Temporary Containers extension.

[EstherMoellman]

... "Houston, this workaround may be a problem" (LOL):

Firstly and if I'm not wrong, your code (Dev Tools) seems to work specifically with TemporaryContainer add-on, and I personally use a more lightweight add-on for TC, so if a user chooses a different TC add-on, he may have problems. I tried to test your code with other TC add-ons, but couldn't make it work.

Secondly, I haven't tested enough, but I wonder if your code needs to be run only one time or everyday. I have no problem in using your code everyday. But I'm sure that most of the average users are not going to be able/capable to use your code everyday.

I don't know if it is doable, but the ideal behavior will be: a) TTBG having complete support for temporary container, including any TC' add-on b) No codes at Dev Tools, everything working automatically c) At same Firefox' session, every tab will be opened in a TC (until user chooses to open it in permanent container or no container) d) At same FF' session, changing groups won't change tab temporary containers, tabs always will be reopened at same temporary container e) At new FF' session, all temporary containers will be deleted, and every tab will be opened in a new temporary container

Again, the steps above describe the ideal world (SimpleTabGroups can achieve everything except point "e" above). Well, If it is doable for TTBG... great! And if it is not doable, then pinned tabs will remain as a workaround for TC, or also your code with TemporaryContainer' add-on will serve as a workaround.

[jingyu9575]

your code (Dev Tools) seems to work specifically with TemporaryContainer add-on

Yes, this changes one of TC's options.

if your code needs to be run only one time or everyday.

Only one time.

a) TTBG having complete support for temporary container, including any TC' add-on

In order to support a TC extension, we have to communicate with it to determine whether a container is temporary, and to create a tab in a new temporary container. Most TC extensions do not support such APIs so this is not possible.

d) At same FF' session, changing groups won't change tab temporary containers, tabs always will be reopened at same temporary container

TTBG won't change containers, but TC extensions may delete them. We need a way to tell TC extension to avoid deleting these containers. @stoically has not implemented this feature yet.

Alternatively, if the option Delete no longer needed Temporary Containers is set to a very long time, the containers won't be deleted and it will work. Currently this option in Temporary Containers can only be up to 15 minutes. The code in my previous comment forces it to be longer, workarounding this issue.

e) At new FF' session, all temporary containers will be deleted, and every tab will be opened in a new temporary container

Currently if the container is deleted TTBG will open the tab in the default container. The API to open a new temporary container already exists in Temporary Containers, but it lacks some options required by TTBG.

[EstherMoellman]

a) TTBG having complete support for temporary container, including any TC' add-on

In order to support a TC extension, we have to communicate with it to determine whether a container is temporary, and to create a tab in a new temporary container. Most TC extensions do not support such APIs so this is not possible.

At SimpleTabGroups or PowerTabs I never had problems with temporary containers. I don't have the knowledge to explain you how these 2 add-ons work well with temporary containers. Perhaps is because these add-ons use extension storage... I don't know. But I can use any temporary container add-on with these 2 add-ons, and when I change groups, temporary containers are always there, always same temporary container. The only collateral effect is that temporary containers with these 2 add-ons are never deleted (until tab is deleted). So, at every FF' session, same temporary containers are going to be there. It becomes a kind of permanent container. Also in the past, due to a FF' bug, temporary container weren't deleted with these 2 add-ons. But I believe this bug nowadays is solved. In brief, in one hand TTBG is powerful because temporary containers really are temporary, and they are deleted at every FF' session. But in the other hand, SimpleTabGroups or PowerTabs also are powerful, because temporary containers remain the same when groups are changed in same FF' session. So I wonder: Can we find a solution in the middle of both ways?

d) At same FF' session, changing groups won't change tab temporary containers, tabs always will be reopened at same temporary container

TTBG won't change containers, but TC extensions may delete them. We need a way to tell TC extension to avoid deleting these containers. @stoically has not implemented this feature yet.

Even if @stoically implements this feature, this will be useful only for his TemporaryContainer add-on, right? Any other temporary container won't work, right? I think that if it is doable, the best will be to find a solution for every temporary container add-on.

Having a workaround for @stoically' TemporaryContainer add-on always will be welcome. But from my ignorant point of view, is a kind of patch, not a solution. Personally I prefer "pinned tabs" as a more simple solution, if you conclude that temporary container can't work with TTBG. My logic in this scenario is the following:

• TTBG will work with any temporary container add-on
• Every tab will be opened by the chosen temporary container add-on
• If users need to keep same temporary container (bank login, email login, any login etc), users can pin tabs (and exclude pinned tabs at TTBG).

This is what I have been using in the past weeks. It seems to me more simple and generalist than forcing users to have specific add-ons with specific codes (Dev Tools).

But hope never dies (LOL)... I really hope you can find a better solution for temporary container & TTBG : )

Thank you @jingyu9575 for all your efforts and the time your are investing in TTBG!

[stoically]

@jingyu9575

The API to open a new temporary container already exists in Temporary Containers, but it lacks some options required by TTBG.

What would be required to meet TTBG's needs?

@EstherMoellman

I personally use a more lightweight add-on for TC

I'm wondering, is the main reason for this the permissions my TC Add-on currently requires? In this case you might want to follow https://github.com/stoically/temporary-containers/issues/201. Or does your alternative offer something special?

[EstherMoellman]

Hi @stoically , is always nice to see you! : )

@EstherMoellman

I personally use a more lightweight add-on for TC

I'm wondering, is the main reason for this the permissions my TC Add-on currently requires? In this case you might want to follow stoically/temporary-containers#201. Or does your alternative offer something special?

Nope, nothing to do with permissions or the issue you pointed. Remembering you, it has to do with a request I did (https://github.com/stoically/temporary-containers/issues/362). Basically I requested you a lightweight temporary container add-on fork, a simple version of your current add-on, with just basic temporary container functions. And I presented you two models, two existing lightweight temporary container add-ons. But after a nice brainstorming, you rejected my request (LOL). As a consolation, you agreed to include at your add-on, the option of making temporary containers as session valid only (deleting all temporary containers at every FF' startup).

No doubt your TemporaryContainers add-on is outstanding. But I do care a lot about browser performance. I'm all the time trying to build the best browser performance structure. So I always prefer lightweight add-ons, simple add-ons, minimalist add-ons. That's the reason I fought a lot in favor of TTBG. It may not be fancy as other similar add-ons... but TTBG is the champ in terms of browser performance.

[stoically]

Aahh, right. My memory certainly isn't the best, obviously. Thanks for clarifying, again! :D

[jingyu9575]

@stoically Hi,

What would be required to meet TTBG's needs?

I'd like to request adding more options from browser.tabs.create to createTabInTempContainer. Right now my extension uses these additional options: windowId, index, discarded, title, pinned.

Also, to solve @EstherMoellman's issue about deleting containers too early, I think your proposed API will help, or an option for longer container.removal.

Thank you!

[jingyu9575]

@EstherMoellman

how these 2 add-ons (SimpleTabGroups, PowerTabs) work well with temporary containers

If the tabs are merely hidden and not closed, TC extensions won't delete their containers.

Even if @stoically implements this feature, this will be useful only for his TemporaryContainer add-on, right?

Yes.

find a solution for every temporary container add-on

The only workaround I can think of, is creating hidden empty tabs with temporary containers, preventing these containers from being recycled. I think it is not a good idea.

[EstherMoellman]

@jingyu9575 , I understand, thank you.

There is no doubt that you always will be capable of creating solutions to any problem. However, in my ignorant opinion, is not worth creating workarounds at any price. For example, favicons workaround flashing, showing pages under background etc, yeah, is a solution, but IMO is not a good solution. And now we have temporary containers, and honestly after favicons I'm a bit afraid of "creating hidden tabs etc". You also are confirming this is not a good idea. So I ask:

Can TTBG' extension storage solve tc issues in an acceptable way?

Or... if @stoically implements changes/new features, are tc going to work at TTBG? Do you want me to formalize any request, by opening an issue at @stoically ' github?

Or... do you believe this is the end of the road for temporary containers & TTBG?

PS: Changing subject, you may want to know that newest 0.2b1 TTBG' version is doubling RAM consumption (from average 500KB to 1MB).

[EstherMoellman]

Hi @jingyu9575 ! How are you?

Do you remember this TabContainer add-on? The add-on works like a charm, and is the more lightweight add-on among its competitors. The Dev @sagitta1618 is a great guy, very responsive, and very fast answering and solving requests. He solved the issue of deleting temporary containers after browser closing. And now, he is trying to solve the issue of keeping same temporary container during same browser session. Here is the GitHub' progress.

Today @sagitta1618 did a huge progress, and now this latest version amazingly can keep same temporary containers during same browser sessions. But sadly it has some negative issues, for example it can't differentiate tabs per tab-groups, so same urls always are opened in same temporary containers, regardless the tab-group.

At this point, I think is good to ask your opinion: 1) Please, can you take a look at the attached latest zip version of the add-on, and make your recommendations or suggestions for improvements? 2) In parallel, do you think you can include changes into your TabToBookmarkGroups, in order to allow @sagitta1618 ' add-on to remember temporary containers per tab (not per url) during same browser session?

I don't know if this is possible to be done, but my feeling is that @sagitta1618 is almost there, he is almost solving the issue with temporary containers and TabToBookmarkGroups. Your help will more than welcome!

I still prefer to use @sagitta1618 ' add-on for temporary containers, because as I said it works like a charm and is lightweight. Now I'm trying to make the perfect married with your TabToBookmarkGroups.

Thank you in advance and big hug! : )

PS: GoogleChrome introduced Tab Groups as a built in feature.

[jingyu9575]

@EstherMoellman I think an option similar to this is needed. See the thread in tabContainer.

[EstherMoellman]

Hi @jingyu9575 , thanks a lot for your help.

The mentioned option you suggested time ago is an useful workaround. But if you remember, my Nightly (with my CSS/JS scripts, add-ons, about:config and many other customizations) is part of an University project where students and employees can test my model, in order to understand the importance and potential of browser customizations. And in this context, unfortunately I can't use your workaround, because this project involves hundreds of Universities over the world, potentially with thousands of testers. Since past January, the project already had more than 5000 testers (downloads). So for me, for my personal use, your workaround is enough, but sadly for my University project I need more simple and common solutions... it's very difficult for me to deal with stuff where testers are kind of "plug and play" minds, they don't want to read nothing, they don't want to know or understand, they don't want to make configurations etc, they are "plug-and play" generation, they just want to turn-on stuff and to use it.

By the way, that's also the same similar reason I couldn't share your fantastic add-on with my testers in this University project. For me, for my personal use, your add-on is a dream, a gem, and works like a charm, it's the most important add-on in my personal configuration. But for my testers, sadly they demand something extra, few pending details to be polished in your add-on. Just as an example, temporary containers was one of these details to be polished... testers need TCs to be remembered during same browser session, but all TC must be deleted in new browser session.

That's the reason I prefer @sagitta1618 ' add-on, it's the most lightweight TC' add-on, time ago I double checked with you if this add-on was "OK", for months it has been working fine, the Dev is great, responsive and solving issues... and it's perfect for my University project, testers need to do nothing, no options, no settings, "plug-and-play", every tab is opened in TC, every TC is deleted after browser sessions, and with @sagitta1618 's and your help, I hope soon will finally see TCs remembered by session. The latest zip experimental version of @sagitta1618 already can do that, the last trick is to remove the undesirable effects and issues of this experimental script.

[EstherMoellman]

Hi @jingyu9575 ,

@sagitta1618 ' latest TC version (updated at AMO) seems to work like a charm. It's very lightweight, and works perfectly with your TabsToBookmarGroups add-on. Basically @sagitta1618 ' TC add-on deletes every TC at every browser startup, so there are no temporary containers when browser is launched. At the same time, during same browser session, it keeps same temporary containers for existent tabs. Again, it works perfectly with your add-on, perfect marriage. Thank you for your help. So, I believe you can close this issue.

I hope everything is fine with you and yours. And I also hope you'll be back soon to keep developing your fantastic TabsToBookmarkGroups. Everyday I've been using it for months, never find a bug, so I believe the experimental period should be over... and perhaps it's time to retake again some pending issues, to incorporate some improvements, polishing some stuff etc. But of course, always will depend on you, if you want and if you can do it.

Big hug and have a nice weekend! : )