Container API

[XavierChanth]

Love the idea of vim keys in the browser, this is the first attempt I've seen that could meet all of my wins for a browser: native keyboard driven, good customization layer, firefox containers.

Really wanted to like qutebrowser and luakit, and I love the webkit engine, but containers are also very important to my workflow.

I would love to spend some time (maybe over the holidays) on a container api, but it would be very helpful to both of us if I first read a CONTRIBUTING.md guide.

[RobertCraigie]

Thanks! There are some contributing docs: https://glide-browser.app/contributing

A container API would be great! I don't personally use containers much, so any insight into what typical usage patterns look like would be very helpful.

[roceb]

Are we talking about Firefox container.. Allows me to keep my life separated. So I have 4 main containers:
Work:

• github
• Gmail
• internal work websites
  Personal:
• gmail
• github
• youtube
• Twitch
  Captain:
• *arr
• pirate ☠️
  Business
• gmail
• other sites

[XavierChanth]

Are we talking about Firefox container.. Allows me to keep my life separated. So I have 4 main containers:
Work:

• github
• Gmail
• internal work websites
  Personal:
• gmail
• github
• youtube
• Twitch
  Captain:
• *arr
• pirate ☠️
  Business
• gmail
• other sites

Yeah firefox containers, I use them similarly. Very useful as well if you've got multiple logins to a site

[RobertCraigie]

Thanks! Additionally, what would you want out of a containers API? e.g.

1. Create a new container
2. Switch containers
3. Update an existing container in some way
4. ... etc?

i.e. what are the most common things you do with containers?

[XavierChanth]

Thanks! Additionally, what would you want out of a containers API? e.g.

1. Create a new container

2. Switch containers

3. Update an existing container in some way

4. ... etc?

i.e. what are the most common things you do with containers?

My workflow consists of a personal container, work container, and a multi-account container where my calendar(s) live so I can take meetings and such across both.

There are three main use-cases I see.

1. Creation/deletion/management of containers for those that like to treat containers as an ephemeral thing
2. Reopening a tab in a different workspace/opening a link in a specific workspace
3. Switching between containers - I have been using floorp and zen both of which have workspaces and I typically map a main container to each workspace

I'm not sure how to do 3, since I believe that stock firefox doesn't have workspaces. But 3 is pretty important to my browser workflow.

It's really nice to be able to jump into my work workspace, without fear of leaking personal stuff if I need to share my screen at work.

But also if I'm doing a demo for a customer/partner, I'm able to hide tabs titles of my confidential work stuff through a second "demo" workspace which is also creating tabs in the work container.

[XavierChanth]

To continue on this thought, I could see this working without a notion of workspaces in the browser as long as there was a containers api.

I would be able to make my workspaces be tab folders instead and potentially have configuration which puts me into personal, work, or demo mode. In which case, new tabs would be created in a specific folder & container.

As a neovim user, I would much rather have an API to build my own bespoke configuration rather than complicate this project's design. As is the neovim way.

[roceb]

Some things that come to mind for my workflow.

1. Create a new container
2. Migrate current site to a container
3. Update name or color of container
4. Create a tmp container for a website
5. Delete a container
6. Set a site to always open in this container
7. Set profiles to a container

[zacharyeller13]

+1 for this being a useful built-in api. I'm currently handling some of these cases with some excmds and the browser.contextualIdentities api but a built-in is a bit nicer. My biggest use-case is tmp containers, which I'm doing somewhat jankily in my config:

let tmpId: number = 0;

async function createTmpContainer() {
    const colors: string[] = ["blue", "red", "green", "orange"];
    let choice = Math.floor(Math.random() * colors.length);
    let color = colors[choice] ?? "white";

    const container = await browser.contextualIdentities.create({ name: `tmp${tmpId++}`, color: color, icon: "fingerprint" });
    await browser.tabs.create({ cookieStoreId: container.cookieStoreId });
}

[RobertCraigie]

@zacharyeller13 what are the parts of the browser.contextualIdentities API that are missing for your use cases? A builtin API for creating temporary containers?

[zacharyeller13]

A built-in api for temporary containers would be pretty nice, but biggest help for me maybe would just be setting every property in the create method to optional so that for short-lived containers I can just call glide.containers.create({}) and let the necessary properties be auto-generated.

Could also be handy to have get_first and active methods like we have for glide.tabs. I could see the argument against glide.containers.active, though, since you can realistically just get from the active tab.

I did wish that tabs.onRemoved passed the full Tab instance instead of just the tabId, because I thought that'd be convenient for managing related containers, but since the tab is already removed when that fires you can't get the necessary info to do so. That limitation is obviously not glide's fault and I worked around it but was a wish I had at first too.