[amluto]

No, but the issue here seems to be a problem with the underlying snap system, not with the concept. It should be possible to have multiple containers that, when run, access the same persistent data. So the workflow would be:

1. Install and start Firefox. There is one container and one directory full of profiles.

2. Start the upgrade. This creates a second Firefox installation (container) sharing the same profile directory.

3. Try to run Firefox without quitting the old one. Does nothing because the runtime is smart enough to know that the old one is running. Maybe pop up a message suggesting restarting Firefox.

4. Quit Firefox. Start it again. The new one runs. All the data is still there.

5. The old installation goes away.

The runtime has plenty of flexibility in how to make this work. There could be multiple containers. There could be one container with multiple parallel versions. There could be one container with a staged upgrade that can swap in essentially instantaneously once the container is idle (although this may fall apart on multi-user systems or where the containerized program regularly has multiple running copies of itself at once, e.g. a program like bash).

But the fact that snap apparently has trouble with this seems a bit embarrassing.

[GauntletWizard]

And snapd has all of the information it needs to do all of this. "Is Firefox Running?" is a tricky question in a traditional package install, because there's a number of ways you can launch a program and "ps |grep firefox" isn't quite right. But that's not the case for snapd! It is the executor and all launches to Firefox have to pass through it; If you launch Firefox while it's running and there's an update queued, it should be able to pass that on to the old version, while still being able to handle "This program is exiting and has an update queued, so let's update it now".

Every critical piece of information is available to Snapd, and yet, they have chosen the wrong and broken implementation.