Support Multi Account Containers

[aphilas]

Problem Statement

Tab Stash isn't container-aware, and loses the assigned containers when restoring tabs.

Most recently, I saved 10s of tabs from GitLab opened in a custom container. On restoring the tabs ("Open All Tabs and Delete this Group"), GitLab redirected me to the login page. After signing in (undesirably without a container), GitLab did not redirect me to the original page.

Previously requested in #104 and #195. Related issues: #125, #169, and #385.

Preferred Solution(s)

Save and restore the container assigned to a tab.

It doesn't seem to be possible to attach metadata to bookmarks using the Web Extensions API. Possible workarounds might be using the title[^title] or the url [^url].

Alternative Solution(s)

Assign websites to default containers (suggested in #104): would only work for trivial usage of containers, unlike the scenario illustrated above. For instance, I have had containers for school, work, and personal, simultaneously logged in to GMail. In this case, I can't assign a default container.

As a first step, an option to save bookmarks using the honsiorovskyi/open-url-in-container protocol scheme as suggested in the MAC FAQs.

Additional Context

It would be nice to indicate that a tab is attached to a container in the sidebar.

It might be desirable to open a tab in a container of the same name in a different browser if syncing bookmarks.

The metadata might be used for tracking? [^tracking]

Storing metadata in urls might breaks web apps if the link is opened without stripping it.

---

Readers: If you are also interested in seeing this feature be developed, please vote for it by giving the ORIGINAL POST a thumbs-up using the :smiley: button. You are welcome to leave comments and discuss the feature request, but "Me too!" comments are not counted by the voting system.

[^title]: tim-we/tabs-aside prefixes the title with a string like [cs=firefox-container-11]

[^url]: use a query parameter, somewhat like the old Places API.

[^tracking]: honsiorovskyi/open-url-in-container uses a signature.

[josh-berry]

Thanks for the detailed writeup and research!

I like the idea of using a signature and adding something to the bookmark title—I think this approach addresses the previous concerns:

• Messing with the URL may make the link unusable by the built-in bookmark feature (e.g. if using a custom URL scheme), OR may break websites (e.g. if appending a custom anchor)
• Messing with the title (e.g. by adding a container tag) opens up a security hole where websites could just append Tab Stash's container tag to their title, convince the user to stash the tab, and then it would later be re-opened in whatever container the site had specified.

Using a signature avoids the second of these concerns because there would be no way for a malicious site to know how to generate a valid signature (since the key would be stored only in the extension's synced settings).

In any case, I'll keep this in mind for a future release!

[douglascaetano]

Another simple solution, that can be taken as a stopgap while a permanent solution is being worked on, is to be able to open stashed tabs in a specific container manually. In other words, one could specifically ask to open selected tabs or a whole group to be opened in a container. I believe this can be a first step towards the solutions proposed in this issue.

[Chealer]

I like the concept of containers. I won't "support" this request for the simple reason that I haven't had the occasion to use them yet, but thank you for this report; it's important to be aware of this limitation for those who do use it. In fact, considering there are reportedly 356 021 users of the containers extension, I suggest highlighting this issue (by "pinning" this ticket on GitHub, or just adding some "Limitations" section to the homepage).

On an organic level, I recommend keeping a couple related issues in mind when architecting a solution:

1. The inability to visually distinguish tab groups, tracked in #432
2. The inability (I assume) to keep track of the virtual desktop (a native feature in most GNU/Linux environments (GNOME and KDE), since Microsoft Windows 10 and (reportedly) macOS 10.5). That issue is not yet tracked.