And for Windows there is standard update mechanism - Microsoft Store - which also does the same sane thing.
So it's Ubuntu implementation problem, and not a Firefox one.
Do I understand correctly that it is based on systemd's offline upgrade mode, i.e. installation is done at the following boot? If so, you can do that on Ubuntu too. I'm not sure how (perhaps by invoking apt-offline?), but at least KDE Discover does it on Kubuntu.
Most software does fine, as long as it has already mapped in all of its libraries, those files can be unlinked in the filesystem, but will remain on disk in their current form. You do run into trouble if the software is part way through starting up and hasn't mapped all the libraries, or if you update the files rather than unlinking and copying new ones (at least, FreeBSD lets you update mmaped files and all processes will see the updates, which is usually not what you actually want when the files are code).
Windows makes it very hard to update program files while programs are running, so it's not surprising Firefox endeavors to do updates while it's not running.
This doesn't seem insane to me, but might not be an easy thing to fit in to the large body of code that's already there.
You still have issues if you're starting up during an upgrade, but that's a problem with anything dynamically linked.
I don't think so? As long as the main process is separate from the seed process, and the seed process is forked before specialization.
> It also makes address space layout randomisation less effective, because every forked process starts out with the same base memory layout, doesn't it?
Yeah, I think you're right. Not sure if you could maybe do some randomization post fork, but you're probably right.
On Windows, where no standard update mechanism exists, Firefox updates itself, so it does it only when it knows it's fully shut down (before it opens or after you close all windows).