Saving media via 'Save Page As…', 'Save Image As…', etc. from within a container tab seem to use the cache used by regular (no-container) tabs. When the URL that is to be saved has not been cached in a no-container context, a new HTTP request is made to that URL, including the cookies used in the no-container context. Proof of concept / Steps to reproduce: 0) Make sure the Multi-Account Containers extension is installed (https://addons.mozilla.org/en-US/firefox/addon/multi-account-containers) 1) Use netcat or set up a web server on localhost. 2) Open a new regular (no-container) tab. 3) Navigate to http://localhost. 4) Answer the request as follows: HTTP/1.1 200 OK Set-Cookie: nocontainer=1; Expires=Wed, 01 Dec 2027 00:00:00 UTC; Path=/; Domain=.localhost 5) Open a new container tab. 6) Navigate to http://localhost/leak. 7) Answer the request as follows: HTTP/1.1 200 OK 8) Click 'Save Page As…' and save as a file 9) A new request for /leak is issued by Firefox, including 'Cookie: nocontainer=1' PS: As a side effect, saving media in containers will result in saving the wrong version if that media has been cached in a no-container context before. For example, saving a URL that returns a logged in user's profile image will store the profile image of the no-container user, regardless of a different user being logged in in the container it is saved from.

This is an extension of Bug 1351155. Given the other is public I don't know if this needs to be hidden.

This is public anyway: https://github.com/mozilla/multi-account-containers/issues/1015 I'm going to dupe with the platform bug.

Is the fix for this bug the same as the fix for bug 1351155? Do they both touch the same part of the code?

There are various methods in source/browser/base/content/nsContextMenu.js that don't take userContextId, the save as ones likely are the easiest to fix. I'm not sure if Image Info will work as easily as is much more complex. We can add a note to fix this specifically in the other bug.