HI Bram, The number 1 request we have gotten from containers feedback is that users want a way to make custom containers. Can you design a manage interface for this (about:containers)? When users click Open Link In Container Tab and see the options for Personal, Work, Banking, and Shopping, we could add a "Custom..." option that would open the management interface. In the management interface, they should be able to name and create a new container. They should also be able to choose a color for that container (or have one assigned by default). We can use a dot of the same color as the icon for that container for now. There should also be a delete button where they can delete a container. There are many enhancements we could make on this (renaming containers, including a default name for users who don't' want to name their new custom containers, letting the user choose icons and colors). But for now lets just start with the basic functionality.

Not sure if it falls under this bug or not, but I'd really like to see one-shot containers. Open a window in a new anonymious containe. When the window is closed the container is deleted. This is similar to private browsing, but allows storage to work fully. Developers really want something like this in devtools in order to test sites in a fresh environment. They can't do this with PB because storage like IDB is inoperable. Devs use incognito a lot in chrome for this and I get told repeatedly it's something we are missing.

(In reply to Ben Kelly [:bkelly] from comment #1) Hi Ben, Do you know if our developers would like this one-shot containers to be able to be created on-demand (one click, or with a keyboard shortcut?). We know that our power user and developer audiences get this feature and love it, so we’d like to make it work as well as possible for them. One of the ways that we’re thinking of doing this is by integrating one-shot containers into DevTools. At the same this, this allows us to not expose this feature anywhere else, because maybe non-developers won’t find it helpful. A early idea: open DevTools, then there’s a button that says “Open this page in a new temporary container tab”. Thoughts?

Yea, putting it in devtools would be perfect. Thanks!

One way that I think containers can integrate within DevTools is via an icon that says “Open page in a new container tab”. It does exactly what it says on the tin, except we’ll open a disposable container that will delete itself when closed and does not have the ability to replicate (ie. there’s no way to open another container tab of the same type). Thoughts? Maybe we should move all the DevTools integration design and discussion into another issue. I do think that containers and DevEdition is a perfect fit.

Comment on attachment 8767808 [details] about:containers - i01 What do the Preferences buttons do? For now, Containers will have the same set of Preferences as the rest of the browser. Can the user rename the container by doubleclicking on the text?

(In reply to Tanvi Vyas - behind on reviews [:tanvi] from comment #8) > Comment on attachment 8767808 [details] > about:containers - i01 > > What do the Preferences buttons do? For now, Containers will have the same > set of Preferences as the rest of the browser. > > Can the user rename the container by doubleclicking on the text? Nevermind! Just saw the second mock which addresses both of these comments! Perhaps instead of "Preferences" we can label the button with "Settings".

Hi Bram, Thanks for these mocks! From this, we can create a handful of development bugs. For the icons, maybe we can add a grey circle to the list. If a user picks the grey circle and the color red (for example), then the icon in the url bar will be a red circle. In the future, we could add more icon options, but for now a circle is generic enough that we could use it as a placeholder.

(In reply to Bram Pitoyo [:bram] from comment #7) > Thoughts? Maybe we should move all the DevTools integration design and > discussion into another issue. I do think that containers and DevEdition is > a perfect fit. We should separate out the devtools integration design into a separate bug. And perhaps meet with the devtools teams to see if they have some ideas.

> Perhaps instead of "Preferences" we can label the button with "Settings". I’m using the wording that about:addons uses for the sake of consistency. An alternative would be to have a button with the gear icon which stands for Preferences, but it’s less clear. > For the icons, maybe we can add a grey circle to the list. If a user picks > the grey circle and the color red (for example), then the icon in the url > bar will be a red circle. This is a great idea! Let’s do that. Another thing to keep in mind is how about:addons is currently undergoing a redesign, and will appear different in the future. I think we should try and match their style. We can also take some of their iconography as inspirations. https://github.com/mozilla/addons/issues/111

Bram's design has been implemented in bug 1267916. It has a 95% complete implementation and review. However, during review, Jared has expressed some concerns with the design. Particularly, he would prefer that about:containers was part of about:preferences instead of a stand alone page. We discussed what this might look like. In Nightly, there is some UI to enable containers in about:preferences#privacy. Next to that, we could have a Customize button that would open a modal. The modal should let you rename containers, delete containers, create new containers, change icon colors, change icons, etc (everything that about:containers does now). We have also discussed needing an alert/message to the user if they try to delete a container that is currently open in a tab (i.e. "You cannot delete this container until you close tabs in the container" or "Deleting this container will close tabs open in this container" with Okay and Cancel buttons). It would be nice if we could just squish what is implemented in about:containers into a modal in about:preferences#privacy. But we can't, because the design depends on modals within about:containers (i.e. to choose a color and icon combination). So we'd need to rethink the design, otherwise we have a modal on top of a modal. Jared, Jonathan and I discussed this over irc. We could have a modal that is similar to about:prefernences#security -> Exceptions. You could add or remove containers. The table would have 3 columns - name, color, icon. The name woudl be clickable and editable. The color would be a drop down (similar to about:applications). The icon would be a separate drop down. The icon would always be grey/black. So the user would see the uncolored icon and the color they choose next to. Depending on the design, they may not see the icon+color combination in the management interface, but only when they open a tab of that container type. We also have to figure out how to alert the user if they try to delete a container when there are currently tabs open for that container. For that, we wouldn't be able to show a modal (since it would cause nested modals). We could make the the management UI expand to show the alert or something. Alternatively, instead of opening a modal when about:preferences#Privacy -> Customize is clicked, we could show the about:containers interface designed here in the same area that about:preferences#Privacy currently is (i.e. making about:preferneces#Privacy temporarily inaccessible) with a back button. You can see that there are addons that do this in about:addons#Extensions: https://irccloud.mozilla.com/file/UtmwH42S/Selection_265.png Clicking Preferences under WebSocket Monitor opens: https://irccloud.mozilla.com/file/mUDhYCCB/Selection_264.png Personally, I think the about:containers design that Bram has come up with is visually appealing (it is pretty). While about:preferences#Applications and the exceptions dialog in about:containers#security are hard to look at. Hence, for that alone, I'd rather not try and use a management interface like these existing ones. I have heard that there may be some work going on to revamp about:preferences, but I'm not aware of the scope or timeframe. Also, since this feature is Nightly only and not intended to ride the trains right now, we can always make the necessary changes to move it to about:preferences when the feature is ready to move beyond Nightly. We could even make that a blocker to move beyond Nightly or Aurora if required. I will set up a meeting with Jared, Bram, and Jonathan to discuss our options. Thanks!

Needinfo'ing Bram for a new design.

(In reply to Tanvi Vyas [:tanvi] from comment #11) > We should separate out the devtools integration design into a separate bug. > And perhaps meet with the devtools teams to see if they have some ideas. Created bug#1295750

What if we put Containers settings in its own page, but give a link to go back to about:preferences#privacy? Then the rest of the interface can stay the same. Have a look: https://mozilla.invisionapp.com/share/7V8BFBVHX

I think this is a good idea! Also because, we can open about:containers in a new tab, or show that page as a modal window on top of preferences as we do for many other settings.

What would this do in terms of http cache? Do containers get a separate http cache instance? For the devtools use case developers may want to avoid http cache issues as well.

(In reply to Ben Kelly [:bkelly] from comment #18) > What would this do in terms of http cache? Do containers get a separate > http cache instance? > > For the devtools use case developers may want to avoid http cache issues as > well. Yes they get a separate cache. Both the http cache and the image cache.

(In reply to Bram Pitoyo [:bram] from comment #16) > What if we put Containers settings in its own page, but give a link to go > back to about:preferences#privacy? > > Then the rest of the interface can stay the same. > > Have a look: > https://mozilla.invisionapp.com/share/7V8BFBVHX Jared and Gijs, how does this look?

Thanks! This is much better and will allow us to share styles without having to pull things out to a shared file. I would still prefer if we just expanded the container information within the Privacy view instead of creating a fake page within it because we don't have this UI paradigm in other parts of the preferences and I don't think it is necessary to do the extra work to hide the other parts of the privacy page. The less subdialogs we have the better too. If it's possible to just put the Add New Container section right in to the page so that a subdialog isn't needed that would be cool, but I'm not gonna make a stink about that.

Thanks Jared! (In reply to Jared Wein [:jaws] (please needinfo? me) from comment #21) > The less subdialogs we have the better too. If it's possible to just put the > Add New Container section right in to the page so that a subdialog isn't > needed that would be cool, but I'm not gonna make a stink about that. I think Bram was concerned about how long the page could get if a user had a lot of custom containers. Also, in the future we may want the ability to tie a website to a container. We don't have a UX for that right now, but I imagine it would take up more space.

(In reply to Tanvi Vyas - out until 8/22 [:tanvi] from comment #22) > Thanks Jared! > > (In reply to Jared Wein [:jaws] (please needinfo? me) from comment #21) > > The less subdialogs we have the better too. If it's possible to just put the > > Add New Container section right in to the page so that a subdialog isn't > > needed that would be cool, but I'm not gonna make a stink about that. > > I think Bram was concerned about how long the page could get if a user had a > lot of custom containers. Also, in the future we may want the ability to > tie a website to a container. We don't have a UX for that right now, but I > imagine it would take up more space. If in the future we need more space we can give containers its own section on the left-hand side.

Sounds like we’ve reached a decision to use the design on comment 16. Thanks for your feedback, everybody. This bug is now marked fixed and ready to implement (let’s file a separate bug for this?)