Hacker News Reader

Comment by kevincox | Hacker News Reader

> prevent it from asking for a restart after update

This isn't just nagging. The API between the main browser context and content processes isn't stable between builds. This means that Firefox can't spin up a new content process if the update has replaced the executable with a different version. Therefore Firefox has the tough choice of trying anyways and risking misbehaviour (including possibly security bugs) or forcing the user to restart the browser process so that it can spawn new content processes.

It also depends on how your distribution updates Firefox. For most distributions they have this problem, however NixOS doesn't because the new version is installed in a new directory.

IIUC Firefox's self-updater also doesn't have this issue, and I think it supports Linux.

View on HN

> This means that Firefox can't spin up a new content process if the update has replaced the executable with a different version.

Couldn't it spin up another one from the old version by doing execve("/proc/self/exe", ...)? Or by keeping a template process around with all the libraries loaded from which a child process can then be forked.

Completely possible, but that's not how it works ATM.

EDIT: And at the risk of stating the obvious, the fact that it doesn't work this way should be a hint that there are complexities involved that make it more complicated than "just" doing it.

I don't agree. The fact that it doesn't work is not necessarily a hint that there are complexities involved. There are a myriad of other possible reasons, such as no one really cares that Firefox forces you to restart the app whenever it updates. People just get used to it.

Or you know, most apps dislike having the executable file itself replaced under them and getting into an unknowably bad state, for basically null benefits. Distros should handle multiple versions of the same program, a la nix, and programs should not optimize for random things like that.

That's just a defeatist attitude. Why does the executable need to be replaced? Why can't the new executable be called firefoxNext, and when firefox starts next time, it checks for this file, and if it exists, it quickly starts that instead, which renames itself to firefox, overwriting the old version? What would be wrong with that?

EDIT: Oh, I see. This happens when the distro package manager updates firefox. I don't have a solution, since there isn't an easy one that will satisfy all people. So nevermind. shrug

Maybe Firefox could create a temporary executable copy of itself and run from there, and run that, so when the original is replaced, it doesn't affect the running process. But, that probably comes with a host of complications that I'm unaware of.

> it quickly starts that instead, which renames itself to firefox, overwriting the old version? What would be wrong with that?

You'd have to enable all users to replace files owned by root somehow - which is a bad idea. Alternatively you'd have to somehow extend the packaging to support owning either/or file and being able to verify the installed files that way - which would be a massive change.

I've been privy to the discussions at Mozilla about this topic. I can assure you, things are not the way they are out of either laziness or ignorance.

I don't know about the `/proc/self/exe` but I think it would work if they use the same binary (I think they do). I don't know how many other config files or libraries may also be read, but maybe those have better comparability.

As for the template process one major issue is that this means that you only get ASLR once on browser start, instead of for every content process, which somewhat reduces the benefits.

Couldn't it spin up another one from the old version by doing execve("/proc/self/exe", ...)?

99% of the Firefox code is in libxul.so, so you'd need to get the file handles from the original process or something similar.

They could have one pristine unused content process and then just fork new ones from that.

On my system, /proc/self/exe is just a symlink to wherever the program is on disk, not a copy or a reference to the image in memory.

If I remember rightly, some of the things in /proc that look like symlinks don't actually behave like them - opening them opens the actual file that the process has open, even if it's been deleted and a new file created at the same location.

Why can't they keep the old version around and continue using it? It just sounds like excuses.

You mean the distros, right? It’s not firefox’s job.

The problem isn't Firefox updating itself; it occurs when the distro update, or other external process, replaces running Firefox.

A workaround would be to use Firefox directly from upstream instead of the distro packaged version (I understand some people are not happy with this tradeoff).

Reply on news.ycombinator.com