How to access the actual Multi-Account Containers per-container site bindings/associations/etc; Are these hiding anywhere?
How to access the actual Multi-Account Containers per-container site bindings/associations/etc; Are these hiding anywhere?
I'm wondering if these are stored anywhere that I can hack directly? Maybe in XML or JSON somewhere? I've done some searching, haven't found anything.
TIA
Solution choisie
The MAC extension stores the subdomain, so you can have support.mozilla.org
automatically open in a different MAC than www.mozilla.org
, for example.
As for your main goal of automatically setting the MAC extension to distinguish between two different Gmail accounts, it's not possible at this time. Since there's no differences between the URL for one Gmail inbox compared to the other, it wouldn't be possible, even if the MAC extension allowed you to set rules for specific pages on a website. There's no way for the extension to tell the difference.
Lire cette réponse dans son contexte 👍 1Toutes les réponses (5)
Is there a particular reason that you want to "hack" this type of information? Generally, the raw access to that type of stored data is pretty rough to read.
You can see the data that the Multi-Account Containers (MAC) extension (and any other extension, really) is saving. They just use Firefox's builtin system for saving extension storage. This can be done by going to the about:debugging
page, selecting This Firefox on the sidebar and pressing the Inspect button next to the extension you want to view.
That opens the developer tools for that extension. You can press the Storage tab and typically see all of the raw extension data that's saved under the Extension Storage section.
In the case of the MAC extension, saved sites are saved using the siteContainerMap@@_SITENAME
key, with information saved in there. Each key has a identityMacAddonUUID
value that matches the macAddonUUID
value of a container, each of which are stored as a identitiesState@@_CONTAINER
key.
However, I wouldn't generally recommend directly manipulating an extension's storage area. It can cause the extension to break or lose important information. If you have some issue with the extension, there's generally a better and safer way to fix the problem that you are having, especially if you have minimal technical knowledge or background.
Wesley, thank you very much for the great explanation. I'm fairly new to MAC and already using it extensively. To answer your question, my motivations: 1) Twice now I've installed / later uninstalled other tab-related extensions that seemed to bork MAC's bindings. I was hoping to be able to at least back them up for safekeeping. 2) I find the MAC's user interface somewhat clunky, and thought it would be great if I could just manage the associations all in one list, rather than the blind, one-by-one, several click per, manual procedure. 3) I'm curious how much of a given URI is used in the associations. Just the TLD? Subdomains? Parameters? One example is I keep separate containers for each of my gmail accounts and want to figure out a way to differentiate them from MAC's perspective. Actually, if you know of an elegant way, I'd appreciate your input, as well as the URI question. Anyways, I did a little scanning of the local storage and, as you suggested, haven't been able to grok anything useful, certainly not in any user-friendly way. Thanks again and best regards.
Solution choisie
The MAC extension stores the subdomain, so you can have support.mozilla.org
automatically open in a different MAC than www.mozilla.org
, for example.
As for your main goal of automatically setting the MAC extension to distinguish between two different Gmail accounts, it's not possible at this time. Since there's no differences between the URL for one Gmail inbox compared to the other, it wouldn't be possible, even if the MAC extension allowed you to set rules for specific pages on a website. There's no way for the extension to tell the difference.
Understood. I have found some URL-ish identifiers for gmail, e.g. https://mail.google.com/mail/u/[email protected] But it redirects before getting the chance to add to a specific MAC container.
I tried to modify one of the siteContainerMap@@_SITENAME keys but it won't let me change it. Or add a new one. I didn't spend too much time at it.
Anyways, I do appreciate the dialogue! And you taught me a few things. Best regards.
Thank you wesley for your reply.
This is actually needed in case of using MAC together with CAD. unfortunately, after decades, firefox sync is still able to get truly basic things wrong. In this specific case, it gets the indices of the containers wrong across devices. The result is that CAD rules exported from one machine and imported into another will be screwed.
Alternately one can manually copy the containers.json into the new profile. This works EXCEPT for the site associations, that, if synced, are then all wrong.
Very sad to see this is even a mozilla-created extension. Unsure if these kind of things are the results or the reason of mozilla difficulties lately.