On Windows applications control their updates, on Linux distros the updates can be triggered externally by the package manager.

Or at least, you get an error if you try and modify an executable that is currently being used by a process on Windows.

Hmm, in that case it seems like the package manager should stage the new update and wait for the process to end before doing the update.

But I suppose linux is generally geared towards servers, where that isn't an issue.

You can get that behavior if you install Firefox from a tar [1], Firefox will then manage its own updates the same as on Windows (though the user running Firefox will need to have permissions to modify the files, which may be risky).

But if you install it through apt or some such package manager, the PM is doing the updates, and it doesn't take into account that Firefox is running.

[1] http://archive.mozilla.org/pub/firefox/releases/latest/READM... has instructions for getting a release tar.

More specifically, Firefox is updating itself in that situation so it knows not to do anything until startup/shutdown. When the you-have-to-restart tab appears, it's because Firefox didn't do the update, something external on linux (apt or snap or something) did it in a way Firefox can't handle.

Not an excuse but that wouldn’t work on a multi-user system of course.

The solution is to version the files and keep the old versions until the processes are closed. As Windows enforces because it doesn’t allow you to delete files that are in use.

Pretty sure that's exactly how it works in the FlatPak version.