Panorama-tab-groups: [Feature Request] Groups using containers

This could be an option but it shouldn't be mandatory. Not everyone wants that level of separation between their groups, for me it's just a way to organize tabs.

I had read the announcement about containers when it was released but I didn't have much experience with it. Since I heard that people were requesting it, I've been using it lately and it's made me think of some things. Namely, that you can't easily convert tabs between containers (at least not natively). So converting a tab to another container involves reopening the tab in that container. In this way, I worry that there will be lag when dragging between groups because the tab has to be constantly checked against that group's container and then closed and reopened if it needs to change containers. And then you'll potentially lose any work that you maybe have been doing in that tab.

I'm not saying that I won't look into it, but I don't think it'll be super easy. Just things to think about for me (or whoever wants to work on it to get it done faster)

@projectdelphai also, there is no guaranty that closing the tab and reopening it in the container would have the required session for the auth user to show the same content. I guess it's probably more of the opposite.

I think containers should be isolated. You should not be able to move tabs inside nor outside a container tab-group.

Right. Moving a tab should be a lossless operation and that requires maintaining user data. Hence, no containers.

there is a lag (a terrible one, actually!!!)
Conex is an example of that!

Yea, it has a lag, and yea, there are constrains for using it, BUT it's the user's decision to use them or not. I vote for having them, but allowing the user to decide if they want to create an isolated container (no tabs in, no tabs out).

Let the user decide.

If this is something that we decide to do, it won't be for a while because of other issues/requests that are more important to bring Panorama Tab Groups up to parity with the original tab groups. So in the meantime, we'll be doing exactly that: letting the user decide. If they want to have a tab group made up of only one type of container, then they can organize it that way manually for now.

I'll leave this ticket open for now and hopefully we can revisit this at a future date (unless someone wants to implement @str's idea and I'm not going to say no to free code contributions as long as it works and isn't obtrusive)

I've seen many tab-group forks and clones come and go. Having a new feature that makes a plugin stand out from the rest could be the killer feature to get more people interested. This is the last thing I'll say about this.

Thank you all contributors for this great plugin.
Thank you a lot.

@str i totally agree it should be the user's choice.

So in the meantime, we'll be doing exactly that: letting the user decide. If they want to have a tab group made up of only one type of container, then they can organize it that way manually for now.

@projectdelphai sorry, can you clarify it (my english is not perfect...)? With this sentence i get the feeling we are already able to set containers to work with groups. But still, i bet i'm wrong ahaha :)

With this sentence i get the feeling we are already able to set containers to work with groups. But still, i bet i'm wrong ahaha :)

Yes, you are: https://addons.mozilla.org/pl/firefox/addon/conex/

By that comment I meant, for example, just name a group "work-container" or something and only place tabs in that groups that are in that work container. Basically PTG does no container work and the user will have to organize their tabs manually.

Not perfect or ideal, but the only solution until someone (or me in the future) has the time to code something up.

Can the plugin just work together with https://addons.mozilla.org/ja/firefox/addon/multi-account-containers/ ?
Like, if the user has multi-account-containers installed together with panorama tab groups, you can set the default tab container of new tabs inside a certain group (when you do ctrl-t, or press the + in the panorama view)
Tabs moved from other groups doesn't have to be re-opened in that container, it is up to the user to reopen that using multi-account-containers.

With this,

1. The performance problem will not happen (like with conex)
2. Panorama does not have to take care of the containers

Tabs moved from other groups doesn't have to be re-opened in that container, it is up to the user to reopen that using multi-account-containers.

What about Pulling instead of Pushing changes on multi-account-containers?
Would it be possible to have an Option in Panorama to "Follow the Lead" of multi-account-containers?
This Mode would hide existing "User created Groups" and simply show groups from multi-account-containers and their associated Tabs. This way you're not affecting any existing functionality (except turn-off dragging tabs between groups).

I think this would move Panorama into the Must-Have category.
I know for me, this is the single biggest issue that I have.

Good to hear that there's so much desire for this issue. Unfortunately it's not my forte nor something on my personal list of things to do since I already have a backlog on it. If someone would like to implement something here, I would be happy to look it over and merge it in. Otherwise, it'll have to sit on the backburner unfortunately.

@projectdelphai

So converting a tab to another container involves reopening the tab in that container. I

There is a way to partially mitigate the problem, IIRC in newer firefox versions (probably 2 years already) there is a method "create sleeping tab", where a tab is created with the web page address assigned to it, but not loaded - until the user clicks on that tab.

+1 for this option

Since the new system, I have now my hundreds (literally) of tabs sorted in containers, more or less one for each project I'm involved in. And I manage them with Conex.

I would be really really happy to manage them more visually, like the old Panorama which I used heavily in the past, with the same hundreds of tabs. But I don't want to reorganize so much tabs in another manner, too much work. If the plugin can recognize all my sorts with containers automatically and use it, it would be so great.

Obviously, it must be a non-default option, and we must activate it knowing what we do!
(And I perfectly know that when I move a tab to another container, I lost my session, etc, and I'm ok with it.)

For this extension, I would say that it could abstract the backend of grouping tabs (not one way hardcoded), and then let the user choose which technique is used to manage groups. If we choose "Use Firefox Containers to group your tabs", and if there are already many containers, we automatically have many panoramas. Obviously, adding a group would add a container, etc.

Is it possible to interop with the multi-account-containers plugin, from a technical perspective?

I'd love to set the default container for a group. Moveing a tab from one group to another should not change its contianer (if this is even possible). Just being able to specify a default contianer for a tab group would cover 99% of my use-cases.