MAC leaves behind tabs which are discarded-on-creation, but are reopened in a container

[josh-berry]

Before submitting a bug report

• I updated to the latest version of Multi-Account Container and tested if I can reproduce the issue
• I searched for existing reports to see if it hasn't already been reported

Step to reproduce

1. Register a domain to be always opened in a particular container, without confirmation (that is, whenever visiting the domain, MAC should be set to immediately reopen the site in a container tab, without prompting).
2. Create a tab with a URL in that domain which is discarded (i.e. the tab is created, but the browser never tries to load it). For example, the following WebExtension API call will do the trick: await browser.tabs.create({url: 'https://example.com/', discarded: true})
3. Note that tab is opened, but not loaded, and not re-opened in a container (so far, so good)
4. Activate the tab by clicking on it

Actual behavior

MAC will notice the tab, and immediately create a new container tab which loads the URL immediately (as expected). However, the tab created in step (2) that is not in a container sometimes—but not always—is left open. That is to say, MAC does not clean up/close this tab, so there are two tabs pointing at the same URL—one in a container, and one not in a container.

The tab not in a container is never actually loaded, however—it's just a blank page. (So this does not appear to be a security issue as such.)

Expected behavior

I expected MAC to close the tab created in step (2) once the new container tab was created.

Additional informations

Some browser extensions will create tabs that are discarded—for example, Tab Stash does this to avoid triggering the loading of too many tabs at once (which may cause performance problems).

This bug causes some bad effects that are noticed by Tab Stash users, for example: josh-berry/tab-stash#425

Provide a copy of Troubleshooting Information page (optional)

No response

[achernyakevich-sc]

Probably your problem could be resolved by playing with add-on settings - Tab behaviour -> Replace tab instead of creating a new one. See below on the screenshot:

If it helps, please, close the issue.

[josh-berry]

This does seem to help. However, I don't understand or agree with your conclusion here:

If it helps, please, close the issue.

The original behavior is pretty clearly unexpected and surprising. It seems to me to be a pretty poor user experience to require people to change an option they don't know about to get correct behavior (i.e. proper replacement of tabs). So I'm going to leave this open for now.

[scovich]

I'm hitting a similar issue -- perhaps related to auto tab discard extension https://webextension.org/listing/tab-discard.html.

Steps to reproduce:

1. Set a site (like github.com) to always open in a container tab
2. Navigate to the site, which brings up "Multi-Account Containers Confirm Navigation" that asks "Open this site in your assigned Container?"
3. Choose "Open in current tab" (do NOT "Remember my decision for this site")
4. Allow the tab to be discarded
5. Visit the tab to wake it back up
6. A new tab will open with the "Multi-Account Containers Confirm Navigation" page (which is NOT in a container), leaving the original tab where it was, with no content loaded.

I confirmed that the preference to "Replace tab instead of creating a new one" does sidestep the problem... but from what I understand it will have unwanted side effects for other use cases like clicking a link in an already-loaded page that should load in a different container.

[scovich]

It seems like we could handle discarded tabs better. Either by remembering the container they were originally using (ideal), or by always triggering the "replace tab" behavior even if the preference wasn't set.