I don't see how snap is faster than apt/.deb. More importantly, apt would update a running Firefox which you can restart later. With snap, Firefox is not updated until you close Firefox and run `snap refresh`.
Worse, they display a misleading pop-up notification telling you Firefox needs to be closed within X days to update. However, closing Firefox doesn't update it, and it doesn't actually tell you how to begin the update or when it will happen automatically. After searching the internet, it turns out you need to open a terminal and run a command to update it manually.
It doesn't seem like Canonical has any kind of UX team, or if they do then they're asleep at the wheel.
I suppose it was always a bit weird, since I shut my desktop down at night so there's never more than a day since Firefox was last restarted.
That hasn't been my experience on Ubuntu for a while. Regularly when updating opening new tabs will display a "just one more thing to do" dialog prompting me to restart firefox. On debian 11, if an update took place firefox will sometimes keep working in a kind of degraded mode (inspect tools don't work for instance) until restarted.
edit: at the moment I can't use netflix until restarted but I don't want to restart because I have a private window with tabs I want to read later.. Sigh.
there is plenty to complain about modern software but "random walk without any intention behind it" is neither fitting nor in any way true nor helpful diagnosis
The reason it no longer works is that tabs run in separate processes. This means that if a tab causes the engine to crash, only that crash (or a small number of tabs) crashes, while Firefox itself and all other tabs keep working, and if there's a sandboxing bug, you still have process isolation which prevents one tab from spying on another. But it also means that if you replace the binary without restarting Firefox, the parent process and the content process will be different versions and they can't really talk to each other.
Software engineering is all about trade-offs. We get improved performance, improved security and improved reliability, and we pay with increased memory usage and a less smooth upgrade process. Personally, I'd say that's a clear improvement.
TL;DR: right after launch, Chrome forks off a helper process which is then responsible for forking off child processes, so that all child processes use the same process image as the main Chrome process. It also opens all files it will need right after launch and just re-uses the same file descriptors, so it always keeps references to the old files. This is complicated and brittle and a source of bugs, but when everything works and nobody makes a mistake, it means the old Chrome can keep running without problems even after all its files have been replaced with those from a new Chrome.
At least that's how it worked in 2011 according to Evan Martin.
https://neugierig.org/software/chromium/notes/2011/08/zygote...
Snap/flatpak/distro packaging is redundant for this. I do the same with Intellij and a few other things. Annoyingly, chrome does not have arch packages so I'm dependent on some community package.
And yeah, you could probably fix that by shipping debs with a statically linked Firefox, but that's not how apt packaging is traditionally done.
At least that's my understanding of things.
Sorry for going on a bit of a rant under your post, but I run into this on the regular.
The fact that the latest Firefox is in rolling release distros/channels but not in stable ones does prove the point a bit; you can either get a new Firefox, or you can get a tested Firefox. I generally prefer rolling releases, but I've had Firefox break in weird ways on Arch from time to time. The only way to get a Firefox that's both well-tested and up to date is to use builds from Mozilla where libraries are bundled, such as with a snap or flatpak.
Firefox (at least in the past) used to break if you updated it while it was running (i.e. replaced / deleted / added files its active runtime depended on). So you had to restart it. In a containerized world, this goes away. i.e. you can replace the firefox "image" with a new one that will be used next time you restart firefox without breaking the existant running one.
with apt/deb you can't do that (besides waiting to update). On a multi user system (less prevelant these days for desktop use, but still existing) this can be really annoying to coordinate.
This doesn't answer if Snap is the right technology to do it, just why apt/deb (and related tech) have issues that they can't really solve.
The same idea applies to all libraries, where the old version of say /usr/lib/firefox/libxul.so can still be referenced by the running firefox process even after apt has replaced it with a new version.
It's not a great system honestly, Firefox will launch new processes sometimes and the IPC system kinda breaks down when the parent process and the child process are from different Firefox versions.