Closed aplatypus closed 4 years ago
Thanks for the feedback!
Unfortunately our experiment doesn't span to mobile which leaves us with an issue around UX for when the tab is opened on a mobile. So in our experiment we chose not to sync to prevent users from opening a synced tab and expecting it to be containerised and instead leak all their cookies to non containers on mobile.
However we have platform bugs to iron out the sync situation and mobile ux. Unfortunately because of this being a test pilot experiment we can't actually fix either of these here. I will leave this open for now to ensure we have captured all your feedback.
I have desktop machines.
I'd just like to synchronize the mere configuration of containers, including their cookies, between all the machines I use Firefox on with sync enabled. I'm not interested at all in synchronized tabs. This seems rather basic and would not conflict with the mentioned mobile use case (I'm using desktop only, but on roughly 10 machines, so sync is essential).
Is this the same issue, or would I better open a separate one?
@groovecoder we need to decide if we should enable some sync features here.
I don't think we can do 3. and 4. and certainly not 5. as part of this experiment.
We could however do 1. and 2. however would this add more confusion that not all sync features are available?
@jonathanKingston @groovecoder The main purpose of Test Pilot is to get feedback on features, to figure out whether they're worth adding and if so, what's the optimal UX, right?
It seems totally clear to me that if/when containers come to firefox proper, sync should work, and it should work for everything listed above.
Add on the fact that I think adding just 1 and 2 would be confusing, and my vote goes against adding sync support at all during this period; it just doesn't seem like a good investment of resources.
edit: Now that the test pilot phase is over, it's surprising to me that there's still no sync. And after using containers for a while, 1 and 2 would be very helpful and 3 would be nice, even if it's confusing why 4 and/or 5 don't work.
Personally, having (1) and (2) is a must. (3) would be really cool. (4) and (5) are irrelevant to me. I've two desktop, and rarely browse on my mobile (when I do, it's mostly to open links I got via IM).
I realize that the purpose of the experiment is to find out what most people like, not me. TBH, the order in which @jonathanKingston listed things above seems the natural order in which to implement them. Any alternative order wouldn't make sense (e.g.:cookies with no container!?).
Hi folks,
for my personal use case I would like to be able to have even different sync accounts per container.
For example, maybe I want to have two sync accounts, one personal where containers like 'personal', 'shopping' or 'banking' are sync, and another firefox account (with my work address for example) for the 'work' container.
I don't think separate sync accounts makes any sense. History is shared, as are a few other things. Syncing all containers with the same account is the logical choice.
@hobarrera, I think the sense depends on each user's case. I'm not saying that should be a feature for absolutely everyone.
But in my case I really appreciate not having to use 2 different profiles, or having nightly and stable open to have a true separation. Containers is a magnificient effort towards making this separation a reallity, but there are several levels.
I totally understand that hooking more than one sync account it could be a completely different project, but, IMOH, it's does make sense to me, at least I definitely will have two accounts, one for work, and one for personal usage.
Definitely let's containers sync first, and maybe other ideas will come later, but language and attitude in a OS project matter.
I didn't mean it doesn't make sense for a user to want this. I meant that your request doesn't really fit into either how weave/sync works, or how containers work.
Currently, a profile contains multiple containers. A [firefox] account syncs the same profile onto multiple machines. I find it rather confusing to think how multiple accounts would sync mulitple containers, but onto a single profile.
Since history is shared: will visiting a page with containerA on accountA also add it to accountB's history? What happens if a history entry is on accountA and accountB, but I delete it on a machine that only has the latter account?
You've suddenly made the sync model extremely more complex (because, essentially, firefox needs to support multiple sync accounts for the same historyStore/cookieStore/bookmarks/etc. Just like these, there are too many rabbit holes like these ones, and, IMHO, and it's a very difference scenario from what's being proposed and done here.
1) and 2) would be awesome, I've been using the containers for a few days, and I keep pestering against it because 2), and then because of 1) :-)
Hi, here's my feedback to help you prioritize:
Maybe you could add a "Vote for me" label on this issue?
Synchronisation would be really nice. If thats not possible a simple import & export option for assignments and containers would also already be a great help in the beginning.
My take on must haves:
Containers (incl. sync) Cookies & storage
… simple import & export option for assignments and containers …
FYI (in the absence of simple/GUI options): https://github.com/mozilla/multi-account-containers/wiki/Debugging-containers#wiki-body with reference to containers.json
and storage.js
files.
To help a little bit in that topic, while waiting for this to be solved, you may use the Containerise add-on with FF 57.
I was wondering why my Sync wasn’t working because my MAC configuration differs between my laptops, then I found this issue. I think what I’m looking for is almost the same thing as @cdrnet – the configuration (which containers do I have, which sites open where) should be synced, the open tabs should be synced if enabled in Sync options.
From https://github.com/kesselborn/conex/issues/15#issuecomment-324244197 (2017-08-23) under Implement backup / restore for conex · Issue #15
· kesselborn/conex:
… (i.e. for moving the session to a different profile or firefox instance).
FWIW
I'm attempting to switch over to Firefox since Quantum's release. Love the concept of multi-containers but not having them sync is actually counter-intuitive for me since it requires me to set them up on 3 separate computers. I had some social media sites setup for one container and was actually surprised they didn't transfer to another computer.
1 and 2 are definitely must haves for me.
My votes: 1 & 2 -> Must have 4 -> Nice to have 3 & 5 -> Don't care
I mostly work on desktop computers on 3 different machines. 1 & 2 are really required there and mobile isn't the major platform for me to work on continuous basis. On mobile Firefox Focus is more than enough.
My two cents: 1& 2: must have. others: don't care.
That said, containers are awesome!
I want to drop my vote as well:
Is there anything that can be done to help speed this up, other than coding? If only coding, could someone with a bit of experience in the codebase offer some pointers to start, or maybe offer themselves up as a mentor-like point of contact? I really want to see container definitions synced :)
1&2 would be awesome!! the rest, less important.
for me.....
1&2 would be really nice rest is less important and would prefer that 1&2 get active ;)
i already copied the .js file to other machines and this is working fine to export the settings but have to be done manually
Mine: 1 & 2 -> Must have 3 -> Nice to have 5 -> Don't care that much.
My scenario is for several desktops/laptops ( Work and Private )
1&2 = must have...... 3....would be nice.... :D
1&2: must have 3&4: nice to have 5: don't care
1 & 2 & 5: must have 3 & 4: nice to have
1 & 2: must have 3 & 4 & 5: nice to have
My votes: 1 & 2 & 3 -> Must have
My votes:
In the mean time, I'll be using the JSON workaround to manually "sync".
My votes: 1&2: must have 3&4: as a option, it is a potential security hole 5: nice to have
Containers need syncing BADLY... Is there a timeline on this?! :\
It would be like sessionbox extension.
-grouping sites -open all site at one time +offline backup like bookmarks
Please enable Sync on Containers ! This is a pain in the a$$ to recreate the same containers on all my desktop machines
I badly need (1) and (2)! (5) would be nice.
1 and 2 would be perfect!
- Assignments
- Containers
- Cookies & storage
- Tabs
- Mobile
Does "Vote For Me" mean voting by commenting?
I am definitely for (1) and (2), and notify the user that only the container names are being synchronized, nothing more.
1 & 2 "must"
3 nice,
4, 5 I don't care
1 and 2 as a definite for me 3 would be nice perhaps as an option for people to choose.
(1) and (2) : must have for me.
1 and 2, please (don't care about the rest)! Seems so natural in combination with Firefox sync that I was kind of disappointed to find out that it didn't sync right away.
I have Firefox Desktop on multiple computers (4 that I use on a weekly or daily basis) and I'd like to sync my containers between them, otherwise I have to manually configure them myself and risk them getting out of sync (hence, why I'd like to sync them ;)).
For 4 and 5 I don't really care but having a synced container experience with cookies included would just be awesome.
1 & 2 are definitely a must have
@moeffju directed me here to comment, any of the 1-5 are difficult, pretty much in increasing order of difficulty.
the open tabs should be synced if enabled in Sync options.
Sync tabs would be hard given this is currently disabled in Firefox given that sync itself doesn't know about what container history is in. This is a very big task.
the configuration (which containers do I have, which sites open where) should be synced,
However this bug could add in sync functionality for container names and assignments much more easily, it still would require careful effort to ensure data is synced correctly to tackle 1 and 2.
Extension sync Syncing data can be done through https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/storage/sync at start up and regular intervals the extension could check the synced version of the data to it's own and decide how to merge datasets together. The biggest limitation is this API only supports up to 100kb of data, which isn't much for assignments. Also this doesn't guarantee performance so the sync code would have to handle that somewhat.
Currently assignments are unique to this extension so it will always have to be done through the extension itself. Container names however would be better synced through Firefox and would free up more space for those assignments.
Container names
The first step of call would be syncing container names the relevant platform bug for syncing container names is https://bugzilla.mozilla.org/show_bug.cgi?id=1288858 it discusses why we haven't done this already and the issues with syncing. If we in future want cookies to match, the CookieStoreId will need to match, which is what makes it much more complex.
From memory we would either need to keep userContextId
in sync or the extension/browser later would have to migrate storage data which would make this a much harder and slower task. The problem with keeping userContextId
in sync means that existing tabs would have to be reopened to a new container.
To handling syncing of anything at this point I would advise creating a new file in: src/js/background/
this would have an init
step similar to the other code and check the synced storage and manage when and how data should be merged together.
Anyone who seriously wants to tackle this should read all the discussion in the Bugzilla thread first and I can try and explain through the problem a bit more.
Thank you @jonathanKingston, much appreciated. Will read through the bugzilla entry and then try scouring the code!
A facility like Containers in not as useful when I can't use it with the Sync facility.
I can use a bookmark group to keep groups of pages together. Because they sync. If I am doing that I don't think I'd "need" containers.