Request browser API change to browser.tabs.update for changing the cookieStoreId of a tab mid-flight

[gaborluk]

Several tab-related issues are mere side-effects of the hacky workaround of closing and then reopening tabs whose content requires a redirect, that is in place because the ideal solution of catching a request mid-flight and changing the cookieStoreId of its tab before we load the content is not available in the browser.

I'm not sure if steps had been taken to resolve this core issue in any way, but my thinking is the following:

1. We should block requests onBeforeRequest to inspect their target URL, and switch to another container if needed. ✔
2. Ideally, if a switch to another container is warranted, then we should be able to fire a call to browser.tabs.update(tabId, {...}), where tabId is received from onBeforeRequest, and be allowed to set the cookieStoreId of the tab to one of our liking. ✘
3. Once the switch is done, we should continue loading the requested resource in the same tab. ✘

This requires a Firefox-specific addition to browser.tabs.update, similarly to that of browser.tabs.create. I'm not sure if there are security or other concerns with this approach, but if none then I strongly feel this should be contemplated, to avoid a growing number of hacky solutions to work around a big one.

@jonathanKingston, @groovecoder, would this be possible?

[groovecoder]

Would only be possible in platform, so I'm going to close this issue. Please file a bug in bugzilla for this.

Note: we've received a family of issues about switching/moving containers and have summarized thoughts and concerns here: https://github.com/mozilla/multi-account-containers/wiki/Moving-between-containers#explanation

[gaborluk]

@groovecoder, my bad, I am aware that this is a platform API change, hence my phrasing "Request browser API change". The issue report had a twofold purpose:

1. Discuss if, according to your experience, this would be a proper solution to a multitude of issues.
2. Have you request the necessary changes, if and when, as you have the necessary street cred for such request, rooted both in your prior experience with the project and relation to Mozilla.

Your article addresses point 1., and I've read it, but much of it doesn't seem to currently apply, as the extension already does the whole closing-and-then-reopening pages, which really is just a poor man's version of switching containers within the same tab – the same privacy concerns apply, except that the latter would carry the potential to be actually optimized for this very purpose from a privacy (and performance, and UX...) standpoint.

In light of that, would you mind reopening this for discussion?

[groovecoder]

Re-opening with the question label to denote this is a question/discussion issue.

[groovecoder]

I think the short answer is that this is possible, but just barely. And the amount of work it would take to do it, combined with the privacy concerns, makes it very low priority for us.

[gaborluk]

Thank you, @groovecoder. I don't quite understand how the privacy concerns are that much different from those of the current workaround which already violates the original privacy considerations from the wiki, but I can't argue with workload and priorities. I just find it a pity that you guys have come up with a pretty revolutionary feature, but it's destined to always feel hackish in everyday use. If you still think this is not worth requesting and you wouldn't do it yourself, then of course feel free to close the issue again, and thank you for your time either way. But in case you are willing to vouch for the request, then just let me know how I can assist with it.

[comicsansgreenki]

+1, this would bring a number of improvements, some QoL (like #1348 - that one drives me up the wall when I'm navigating between sites with their own containers). I hope this is still on someone's mind or list, even if low-priority.