Associate userContextId=0 with default container (fix can't open in default container if url assigned to a container #1312)

[garywill]

Background is #1312

"Open link in new container tab -> No container" doesn't work if the link is to the current site which has been set "always open in" current container

After debugging I found browser.tabs.onCreated is called twice.
The first call is ok. tab.cookieStoreId = firefox-default.
But the second call tab.cookieStoreId = firefox-container-x. The container id is not desired.

Then after digging the code, found in reloadPageInContainer() variable let currentCookieStoreId; is left undefined if currentUserContextId is false. That caused unwanted behavior.

[jonathanKingston]

@garywill is this causing the code to do anything different or console errors?

My understanding is properties being undefined should use the firefox-default as that is how the extension APIs should work. (I would prefer we didn't pass undefined for the record, however I'm not sure if I prefer explicitly doing it either as this code might not account for future changes in Firefox either for example private browsing may eventually be supported).

[jonathanKingston]

See my other comments however if we need this I would prefer all non test usage has a global.

[garywill]

is this causing the code to do anything different or console errors

Yes it is causing browser doing different. No console warning or error is showed. And there's some odd behavior still confusing me.

If leave the variable undefined :

• A tab with the comfirming page url is opened with tab.cookieStoreId = firefox-default. This seems ok.
• After 0.5 sec, the tab closes automatically. Then immediatly another tab with the comfirming page url is opened with tab.cookieStoreId = firefox-container-x. (as I described above)

It's the second one that is undesired and giving user unwanted container. I have no idea why this happend. These behaviors can be observed by adding console.log in browser.tabs.onCreated.addListener (I did it on Firefox 68).

[garywill]

private browsing may eventually be supported

Some time ago this addon could be set as allowed in private window. But in private window user can't open any container tab, browser console shows Error: Illegal to set non-private cookieStoreId in a private window.

After "incognito": "not_allowed" was added in manifest.json, no longer this addon ran in private window. I don't see any sense to use this addon in a private window. Is there any plan to do that? Or is there any thing I miss?

[garywill]

According to Firefox source code, default container has userContextId=0

https://searchfox.org/mozilla-central/source/browser/base/content/utilityOverlay.js#776 in function createUserContextMenu()

 // If we are excluding a userContextId, we want to add a 'no-container' item.
  if (excludeUserContextId || showDefaultTab) {
    let menuitem = document.createXULElement("menuitem");
    menuitem.setAttribute("data-usercontextid", "0");
   .......

Addon's background logic didn't associate 0 with default container. userContextId should return 0 when cookieStoreId=firefox-default
Incognito mode don't have cookieStoreId, userContextId can be false

After changing, it seems no unnecessary reopening, so test fails. (Not that reason, sorry.) Now tests pass.

I also did some simple test (manually, with eyes) on some cases needing reopening. When opening example.com(which has been set "always open in container") in new tab, reopening works.