| 8 Feb 2024 |
 @doti:catboyindustries.co | 
Download image.png | 01:17:59 |
| @doti:catboyindustries.co | then you can click manage site list and remove a specific site | 01:18:07 |
| 12 Feb 2024 |
|  Janik (they/them) joined the room. | 00:35:39 |
| 18 Feb 2024 |
 Don Rudo | is there a way to track the history for a specific container? I am trying to keep some sites within the container enabling the "Limit to designated sites" on, but seems like a few redirects are missing and are kicked out when I start a new session from it unless I disable the option. | 21:10:29 |
 Danny Colin | History isn't aware of containers. | 21:32:43 |
| Danny Colin | That needs to be implemented in Firefox itself. | 21:34:11 |
| Don Rudo | I see | 21:44:54 |
| 23 Feb 2024 |
|  pam_cakes joined the room. | 18:47:04 |
| 29 Feb 2024 |
|  deranged_giraffe_39 joined the room. | 02:26:26 |
| deranged_giraffe_39 | Hello. I love Containers, and use it extensively. I have a minor UX problem though: I use the always open <site> in <container> feature for some sites I use a lot, but I also have multiple accounts on that site in two containers. So when I'm using another account on that site in another container, every time I click a link or type in a url it asks me if I want to switch containers to the main one. This is very annoying just because it happens so often. Is there a setting or something I just didn't see that fixes this? Ideally I'd be able to 'always open <site> in <container> unless I'm already in <other container>' and never see the which container message, but anything in between is fine. 2) If not, how feasible is it for me to make a local fork of containers, add that, and then switch to it? Would there be an issue where I don't have the right key to sign it or something so I can't use the same plugin data storage that currently has all my container info? | 02:34:57 |
| deranged_giraffe_39 | I guess if there's a way to make another extension that acts as a plugin for containers that modifies its behavior to do that that'd be better than replacing it | 02:37:29 |
| Danny Colin |
- No. The only option currently is to not assign the website to a container and manually open a container tab first.
- No idea how much work it'd be to implement this feature. If you make a fork, you'll have to reconfigure your containers in this new addon. Again, you can probably create script to migrate your data but that's more work to put in.
| 02:53:08 |
| deranged_giraffe_39 | Thanks, oh well. | 02:56:29 |
| 3 Mar 2024 |
 Cimbali | I’ve made a local fork for this exact reason deranged_giraffe_39, several accounts don’t fit the single unique site-to-container mapping | 23:52:29 |
| Cimbali | So my 2 cents:
- It’s easy enough to export your previously existing container assignments by inspecting the extension storage, re-importing them in a fork is something you’d have to implement from scratch though
- There’s no key issue if you just change the container id. That means that interactions where this container identifies itself using that key (typically mozillavpn integration) won’t work with the fork
| 23:53:35 |
| Cimbali | * So my 2 cents:
- It’s easy enough to export your previously existing container assignments by inspecting the extension storage, re-importing them in a fork is something you’d have to implement from scratch though
- There’s no key issue if you just change the extension id. That means that interactions where this extension identifies itself using its id (typically mozillavpn integration) won’t work with the fork
| 23:54:15 |
| Cimbali | * So my 2 cents:
- It’s easy enough to export your previously existing container assignments by inspecting the extension storage, re-importing them in a fork is something you’d have to implement from scratch though
- There’s no signing issue if you just change the extension id. That means that interactions where this extension identifies itself using its id (typically mozillavpn integration) won’t work with the fork
| 23:54:27 |
| Cimbali | * So my 2 cents:
- It’s easy enough to export your previously existing container assignments by inspecting the extension storage, re-importing them in a fork is something you’d have to implement from scratch though
- You can’t sign an addon with mozillavpn’s id, but there’s no signing issue if you just change the extension id. That means that interactions where this extension identifies itself using its id (typically mozillavpn integration) won’t work with the fork
| 23:54:52 |
| Cimbali | * So my 2 cents:
- It’s easy enough to export your previously existing container assignments by inspecting the extension storage, re-importing them in a fork is something you’d have to implement from scratch though
- You can’t sign an addon with firefox container’s id, but there’s no signing issue if you just change the extension id. That means that interactions where this extension identifies itself using its id (typically mozillavpn integration) won’t work with the fork
| 23:55:49 |
| Danny Colin | Yea MozillaVPN checks the addon id sending messages and only accept MAC. However, you could use the advanced proxy if you can get a SOCK url for the VPN servers. | 23:56:24 |
| Cimbali | Unless you fork mozillavpn too, that is. 😁 | 23:58:20 |
| Danny Colin | Ahah true. | 23:59:41 |
| 4 Mar 2024 |
| Danny Colin | By curiosity, Cimbali did you ever play with nekho (networking code in Firefox)? | 00:00:21 |
| Cimbali | No I don’t know what nekho is tbh | 00:00:43 |
| Danny Colin |
The Necko (aka Networking) component is Gecko’s implementation of the web’s networking protocols.
| 00:01:20 |
| Danny Colin | tl;dr any request you make to an (http,proxy,etc) server is handled by it. | 00:02:03 |
| Danny Colin | The WebRequest API uses it under the hood too. | 00:02:19 |
| Danny Colin | I was asking because I wanted to move the assignment system of MAC directly in Firefox and expose it as an extension API so we don't depend on MAC anymore for that. | 00:03:50 |
| Cimbali | Hmmm. And that would reside in necko? | 00:04:21 |
| Danny Colin | No but the new assignment system would call nekho interfaces directly instead of using WebRequest. | 00:05:02 |
