multi-account-containers

multi-account-containers copied to clipboard

"Always open this site in..." is wonderful. If I don't flag the "Remember my decision for this site", every time I can choose if open in container or not. It would be very useful extend it with the ability to choice between multiple containers (the ones I have previously chosen). So, when i type office.com, Containers will show me "Personal" container or "Work" container.

Yes please!

I want an option to always prompt for a container for certain sites that I created multiple profiles in, but only if the source was not already open in a container other than the default.

In effect, I'd like an option to always open a site in an unspecified non-default container.

I'd like to add that assigning multiple containers per site is very much in line with addon stated goal of

Firefox Multi-Account Containers lets you keep parts of your online life separated into color-coded tabs. Cookies are separated by container, allowing you to use the web with multiple accounts and integrate Mozilla VPN for an extra layer of privacy.

Here’s a proposed design/flow for this feature:

• The “Always Open this site in …” panel becomes a list of checkboxes:

• Selecting/un-selecting a value no longer re-opens the current tab in that container

• Rename the context menu option accordingly:
  
  (text could be adjusted, e.g. “this Site”, add container name…)

• checking/un-checking the context menu checkbox only does/undoes the assignment to the current container without affecting the site’s assignment to other containers

• When a URL assigned to a single container is opened, behave just like before

• When a URL assigned to more than one container is opened and “Remember my decision” was never selected, open the confirm page with all assigned containers as options:
  (not sure how to display when there are e.g. 10 assigned containers?)

• When a URL assigned to more than one container is opened, and “Remember my decision” was selected:

  • if the URL is opened in an assigned container, open in the container
  • if the URL is opened in any other container, open in the remembered container

• To undo the “Remembered decision” simply undo/redo the container assignment. This is the same behaviour as currently but made a little more accessible through the checkboxes panel. This seems intuitive but could also use an additional UI.

---

I just want to clarify the “Remembered decision” with an example, using the confirm page screenshot above.

Say from that confirm page for about.gitlab.com, I check “Remember my decision” and select the “Work” container. From now on, when opening about.gitlab.com:

• in the Work container: opens the tab in the Work container
• in the Personal container: opens the tab in the Personal container, as this is an assigned container
• in the Shopping container: opens the tab in the Work container
• in the default container: opens the tab in the Work container
• etc.

Essentially, the remembered decision is what to do when a website is opened in none of its assigned containers. This allows to set a container as default, while still allowing other containers to be assigned too. If people want to always be prompted then just don’t tick “Remember decision” (or undo it as explained above).

Is there any way to maybe get UX feedback on this proposal? I’m not sure who to ping to get this looked at, @dannycolin do you have a suggestion maybe?

@dannycolin I think this could be closed as a duplicate of #1749, which sounds like it could use some attention finally. Speaking of, does this org have the ability to fund issues?? This is becoming important enough at work that I'd donate a little for the community to benefit sooner.

I have an implementation already, which I used to make the mock-ups. Used it over the past 2 months and didn’t notice any issues. I can share in a PR but was advised to wait on UX input before talking code.

@Cimbali It looks like I would have to switch to the nightly builds of firefox to test a locally built extension. Sorry I don't have the time to get into that right now. Let me know if there is another way I can test or help this move into a PR. Thanks for contributing!

@dannycolin I think this could be closed as a duplicate of #1749, which sounds like it could use some attention finally.

As I said on Matrix, I'm not a paid staff and I don't really have the bandwidth to review substantial patches like this one at the moment.

Somewhat related to this issue, I mentioned that it'd be preferable to move the website assignment mechanism in Multi-Account Containers to Firefox itself and expose it through the ContextualIdentity API. This would allow 3rd parties addons to implement this kind of feature without waiting on Mozilla while being compatible with this addon by sharing the set of rules.

Here’s a release of the fork multiply-assigned-containers_v9.0.9.zip (changed the name for clarity, it’ll install as a different add-on -- it’s signed by AMO so no need to use nightlies but use at your own risk)

As I said on Matrix, I'm not a paid staff and I don't really have the bandwidth to review substantial patches like this one at the moment.

Not a matrix user, sorry. Is there someone else that could be pinged to review this? Having to open the specific container in advance is a real bummer for users.

Somewhat related to this issue, I mentioned that it'd be preferable to move the website assignment mechanism in Multi-Account Containers to Firefox itself and expose it through the ContextualIdentity API.

Sounds neat! But I still think it would be best to get this merged since it's clear the functionality would offer a lot of end-user value without adding much complexity.

@Cimbali Could you please open an official PR so we can move the discussion there?

I could open a PR but that would likely move the discussion to the merits/defaults of the implementation choices I’ve made to create a mock of this feature -- rather than defining what maintainers would like to see from this feature.

I’m not sure what the best approach here until we get some input.

If you want to look at the changes this PR entails, you can look use the github code comparison. Changes are conceptually simple (essentially a single assignment becomes a list), the the devil is, as always, in the details.

@Cimbali I know, and it's very possible that they just close it, but the code will still have value and opening a PR would give it visibility. But, more importantly, reading between the lines of @dannycolin's limited time, I don't think you are going to get the input you need if you can't get someone at mozilla to review this. PRs indicate that it's time for review and discussion. Some organizations do a good job of fleshing this all out in issues or discussions, but I think that's not what will work here. Mozilla has a reputation for being very disorganized.

@Cimbali I think we should scale down a little bit:

1. The bug report was opened to have more flexibility on the containers offered as an option to open the site in. This means I don't feel comfortable to redesign "Assign site to container" to allow multiple choice. I'd like to keep our focus on the confirmation page for now. We can work on the other part of your proposal in a follow-up bug.

2. For the confirmation page UX, I feel like a dropdown menu where the assigned container is the default one would be a better solution. We could take this opportunity to also fix the "Remember my choice" checkbox. In this scenario, the checkbox would confirm the assignment to whatever the container selected by the user.

It could looks like:

[Personal (default)]
[------------------]
[ Work             ]
[ Banking          ]
[ Shopping         ]

[ ] Remember my choice and don't show me this page again.

It could looks like:

@dannycolin we have #2294 with proposal about that changing UI structure of the Confirmation Page with similar but slightly different UI. If the UI you proposed in the previous comment is ok and will be supported by the community then I would propose that I will dedicate one of my developers to implement it.

Is it ok?

@dannycolin if you don’t allow multiple container assignments per site, then where does the selection of containers on the confirmation page come from?

• Just current container + assigned container? That’s what we have today and only requires 2 options.
• All of the containers? Then we’re re-implementing the “reopen in container” menu in a weird place.

Note the original request specifically says:

It would be very useful extend it with the ability to choice between multiple containers (the ones I have previously chosen).

Really this confirmation page UX assumes that the multiple container assignment is already possible.

@Cimbali It is more like a "life-hack". :)

I will explain it. For the security reasons and trying to improve UX current implementation assume that after assigning URL to some container (to always open this kind URLs in this container) first time it will happen user will not get container switched but user will be informed that it would happen and asked to confirm by checkbox his wish really do not see this windows again. This UI is very misleading and cause many misunderstanding and this is why I created the proposal to change it (#2294). There you could find links to related issues and so one.

But this opens the door to try to use it - people never set checkbox to finally confirm and this way could every time select what container it will be open - that page loading was initiated or that is assigned as default.

So combining UI/UX of #2294 and what Danny described in your comment we could have resolved misunderstanding reasons and implemented your request. :)

It would be very useful extend it with the ability to choice between multiple containers (the ones I have previously chosen).

I don't read this as offering multiple buttons for this containers. I think the dropdown is still a better UX solution.

In the future, we could always show "frequently used containers for example.com" at the top of the list. Something like this:

  <select name="container-list">
    <optgroup label="Frequently Used">
      <option value="">Personal</option>
      <option value="">work</option>
    </optgroup>
    <optgroup label="All Containers">
      <option value="">Banking</option>
      <option value="">Shopping</option>
      <option value="">...</option>
    </optgroup>
  </select>

The main goal, here, is to keep the UI changes as minimal as possible while making it more user-friendly to open a site in a different containers. There are multiple reasons including:

• The UI is already overly complicated
• The checkbox in "Always open in" makes it looks like you can assign a site in multiple container while it isn't the case. The assignManager doesn't support it currently. Adding this support would need a whole lot more work both code and design for which we don't have the bandwidth at the moment. Plus, there's work to move the assign in Firefox itself so we should avoid duplicating the work.

So, lets keep iterating slowly but surely ;)

Fair enough @dannycolin it could be previously used containers for a website – that still requires significant changes, in this case to keep track of which containers were used for each domain. That sounds like it could quickly become an awful lot of data, too.

Also can you point me to the work moving the assign to Firefox itself? (If there’s a bugzilla issue or something?)

that still requires significant changes, in this case to keep track of which containers were used for each domain. That sounds like it could quickly become an awful lot of data, too.

That's why I said "in the future". In any case, what I'm proposing is of course close to "reopen in..." but it has the advantage the still let you keep the website assgined to a default container. This isn't something possible with "re-open" because you're ending up in a loop that always end in the default container.

I totally understand it isn't a perfect solution but allowing multiple container assignment would be a major rework.

Also can you point me to the work moving the assign to Firefox itself? (If there’s a bugzilla issue or something?)

I haven't published notes on it because it still is in the early development stage but bug 1823065 will be the ticket to follow.

@Cimbali and @achernyakevich-sc definitely feel free to get in touch with me on Matrix if you want to discuss more about this new API.