Two use cases that we would like to solve with this change: 1. Users would like to be able to change "new tab" to open in the current opened container 2. Users would like to be able to change default tabs to be containers that get thrown away. This would also solve taking cookies from a temporary container that could be thrown into a long term container so auth could be shared. This would include but not be limited to: 1. Ctrl+t 2. Clicking on the + tab button (without clicking on a container) 3. An extension creating a tab without a cookieStoreId Edge case to consider: 4. First tab opened by the browser Similar cases that could potentially be controlled by the extension in a follow up bug: 5. Clicking on links from a container/default tab. Implementing this would give containers (or other extensions) the ability to solve Bug 1376118. This is also what Taborama extension implements by monitoring for "firefox-default" tabs, closing them and creating brand new tabs with the correct cookieStoreId. This is essentially the hacky way of implementing this feature which causes the user to see the tab switch. Extensions like "Containers on the go" would likely implement use-case 2. for increased private browsing by default. I listed 4. and 5. as this might impact API design if this were approved. We should also consider if this would be implemented like one extension at a time can be in control of this feature at a time. The API could for example be controlled by a browserSetting which might look like: browser.contextualIdentities.defaultCookieStoreId.set({ value: "firefox-container-1" }); Acceptable values would contain: For normal windows: "firefox-default" and "firefox-container-[0-9]+" For private windows: "firefox-private" and "firefox-container-[0-9]+"

There was another bug about converting an existing tabs cookie store. I think these can be not related where that bug will improve this functionality. Changing a tabs container likely requires a lot more work and digging into how to implement that without breaking container guarantees. This however doesn't.

Hi jkt, this has been added to the agenda for the October 31 WebExtensions APIs triage meeting. Would you be able to join us? Here's a few things about the triage to keep in mind: * We normally spend 5 minutes per bug * The more information in the bug, the better * The goal of the triage is to give a general thumbs up or thumbs down on a proposal; we won't be going deep into implementation details Relevant Links: * Wiki for the meeting: https://wiki.mozilla.org/Add-ons/Contribute/Triage * Meeting agenda: https://docs.google.com/document/d/1qqE6fkqr-RNWaFvMpv0Z8O5FLDgQ3AT5eGdbTt7lRGg/edit# * Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision

Sounds good, thumbs up from everyone in the meeting.