Thanks for filing this bug Alfred! Bram (our UX designer) did have some ideas on how we could integrate this with bookmarks.

Hi Alfred, Have a look at our earliest iteration of the design: http://cl.ly/dUJB This design has moved forward from that iteration, but the difficulty remains the same: * We have two states: when you’re outside of a container, and when you’re inside, and things may behave differently * We cannot convert a non-container tab into a container tab or vice versa. We cannot migrate your sign in state and site data into, between, or out of a container. * It would be really nice if we can do this * My hypothesis: users expect that when they bookmark and assign a container, “all my stuff just moves there magically”, and they don’t have to worry about signing out and signing back in again. * However, it’s very hard, if not impossible, to accomplish With the caveats out of the way, here are some bookmarking behaviours that I think is right for the current design: * Bookmarking from outside of a container * When adding bookmark, you can select a container for the URL * Sign in state and site data will not be migrated into the container; you’ll need to sign in and sign out manually * When deleting bookmark, you will lose the quick shortcut * Sign in state and site data will not be deleted * When you edit the bookmark, you can change its designated container, or not pick any container * Sign in state and site data will not be migrated into another container * Bookmarking from inside a container * When adding bookmark, we will automatically assign a designated container for the URL * You can change this designated container, but sign in state and site data will not be migrated into that container * Accessing bookmarks using the location bar * When you type a matching URL, we will show and select the bookmark by default * We visually indicate that the bookmark will open in a container * You can open URL outside designated container, but it’s not the first option on the list * Accessing bookmarks using the Bookmarks menu * We visually indicate that the bookmark will open in a container * You cannot open the item outside its designated container I am probably missing a lot of corner cases. What do you think?

If containers/usercontext is seen as a kind of "profile" with its own state/login/password/etc, then it makes sense that when bookmarking inside a container that bookmark is only valid within that container (ie. my banking url's inside the banking container). Moving/reusing bookmarks across containers is a different thing. A shopping URL doesn't make much sense in banking context (but you may want to check the account before buying?) And what about accesing the same bank during the checkout/payment phase of a shop?. This all needs to be investigated / clarified using user scenario's.

The feature we have in mind and are implementing now does not have a separate "profile" with separate preferences/logins/history/etc. This is shared across all contexts. Bookmarks are tricky - you may want to open a bookmark in the context of the current tab, or you may want to open it in a different context. If you are logged into shopping.com in the Shopping profile and logged into paypal.com in the banking profile, you won't be able to purchase something on shopping.com with paypal without re-logging in. You are right about this.

This bug requires UX work, UI work, and platform work. We could break this into three different bugs if we want to easily distinguish them and call this a meta bug. But note it is not a P1. Since it is a lot of work, we wouldn't get into this until after we have collected the first round of feedback We are still trying to figure out how to manage contextual identity bugs, but for now I'm going to mark this P3 and distinguish bugs that are not needed for the initial launch as P3.

Is there a mockup of the latest design iteration, like http://cl.ly/dUJB earlier?

We need some option field for container which will be set across bookmark > properties. Now we must all opening action do manually: open container, open bookmark, etc. We need possibility to open one or more bookmark (from bookmark folder) with the same origin (via simple click or context menu) in a previously defined container for them.

Adding :markh because storing the `userContextId` for bookmarks will have implications for Sync, too. We should keep this on our radar, along with bug 1283320.

Bug 1288858 has some interesting discussion about the implications for sync.

Bulk change per https://bugzilla.mozilla.org/show_bug.cgi?id=1401020

Is it possible not to implement this feature? It would be very inconvenient if bookmarks will be removed when a container is removed. I need to see the whole set of bookmarks.