Not the OP, but I consider it a soft crash every time I update Firefox in my OS, and it won't allow me to spawn new tabs until I restart Firefox. Annoying behavior they've included a couple years back.
If I understand what you're reporting correctly, then that's something your OS "included a couple of years back".
If you install Firefox from Mozilla's site, it won't have these update problems. What's happening is that your package manager is swapping Firefox's bits out from under it while it's running. Firefox's built-in update system doesn't do that.
Which is not to say that I think you shouldn't be using a packaged version of Firefox. Personally I'm running Nightly so I don't have the option anyway. Generally speaking, I vastly prefer sticking to my package manager's stuff.
I just wish the package managers would fix their Firefox updates. (I don't know what the right fix would be, and I imagine it could be hard.)
Then someone at Redhat was probably bribed by some Googler, cause it only happens with Firefox updates /s
Joke aside, Firefox is aware that it's been updated and the new tab states that I have to restart my browser. I'm not familiar with the inner workings of Firefox, I just expect it to have everything it needs to function, in working memory. I've been using Fedora for close to 14 years now, Firefox always installed from system packages, and the updates always replaced the existing files on disk without it affecting my application experience. No other desktop app I use has this behavior after updates while they where running.
A big fuss? No, got used to it already. But I still consider it a soft crash state that I encounter with Firefox.
Er... just yesterday I had the crappy update experience that everyone is talking about. And that's using Firefox Nightly, with a downloaded build. So I'd need to look more into this to understand what the actual situation is.
Hm... though now I wonder... I also had a cron job that ran me out of disk space. I wonder if that contributed to make it more like the external file replacement situation?
Strictly, Fedora doesn't support doing updates while the system is running (or at least they don't recommend it).
An alternative that might be smoother in this regard: use a flatpak version of Firefox instead. (Firefox is in Fedora's flatpak repo, and on Flathub.) GNOME Software updates flatpak apps in the background, and you just get the new version the next time you open the app.
Not sure from which perspective your comment comes from. dnf update or dnfdragora updates (if you prefer a GUI) are all done while the system is running.
Sure, distribution upgrades nowadays are just like Windows update requiring a system reboot and a black screen with a useless progress bar to stare at (that's also a pretty annoying relatively recent addition).
GNOME is not my cup of tea. And until flatpak delivers tangible finegrained software sandboxing (at least Android level sandboxing), I'm not really interested in using it for software that's already packaged in the dnf repositories.
I use Fedora because it has newer software, pretty stable in my experience, and my knowledge is transferable to RedHat/Enterprise Linux. But I stopped buying into most of Redhat's desktop innovations a while ago.
> Not sure from which perspective your comment comes from. dnf update or dnfdragora updates (if you prefer a GUI) are all done while the system is running.
> Sure, distribution upgrades nowadays are just like Windows update requiring a system reboot and a black screen with a useless progress bar to stare at (that's also a pretty annoying relatively recent addition).
Silverblue doesn't have a black screen with a progress bar — it just boots straight into the updated version. I assume Kinoite (like Silverblue but with Plasma instead of GNOME) is the same.
> And until flatpak delivers tangible finegrained software sandboxing (at least Android level sandboxing)
It's cool, I get it. You find these adequate solutions to existing problems. But they are replacements of some issues for new issues. That's why I'm not onboard with Redhat vision for a Linux desktop, that's why I stay away from GNOME, Flatpak, rpm-ostree distro flavours. They are almost an 80% of something, then a coin toss away of being deprecated/ignored.
Those tools are not teaching me how to fish, but how to carve out and build a fish rod, fish anatomy, and anything in between. When all I want is the proverbial fish.
Things got dicier in the server space since the IBM acquisition, e.g. RedHat 8 experience was anything but good, and their entry into the container space with UBIs. A pile of things breaking, when switching the Dockerfile from CentOS to RedHat. Even more ridiculous things, like RedHat 8 offering a license that allows X install for free, but then the ISO wasn't even distributed by torrent file and the download speed for me in EU was under 100KBps.
But anyway, here I am ranting about RedHat, when I didn't want to. My main complaint is still with Firefox, it wants me to restart the browser but I can use the existing tabs just fine for any web browsing. Nothing is bricked by the update, just Firefox deciding when I should restart my browser, just like the very vague Windows experience I left so long ago.
You just probably use the web browser much more often to catch it after an update.
And afaik, the reason for this is that they can only maintain a known good state this way, as well as making freshly patched security patches available as soon as possible.
I don't think the package managers are at fault here and this would be much more easily fixed in Firefox itself by not touching the filesystem after Firefox starts - resources are already bundled so you only need to keep a handle open (package managers don't change file contents but replace what the filename points to) and only fork instead of executing new processes (keep a pristine process running to fork from if you want).
