4 ms·

> 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 betwee

> 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.

the8472 5y ago
> 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.
- dblohm7 5y ago
  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.
  - phendrenad2 5y ago
    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.
    - kaba0 5y ago
      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.
      - phendrenad2 5y ago
        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.
        viraptor 5y ago
        > 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.
    - dblohm7 5y ago
      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.
- kevincox 5y ago
  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.
- rockdoe 5y ago
  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.
  - account42 5y ago
    They could have one pristine unused content process and then just fork new ones from that.
- kelnos 5y ago
  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.
  - makomk 5y ago
    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.
phendrenad2 5y ago
Why can't they keep the old version around and continue using it? It just sounds like excuses.
- kaba0 5y ago
  You mean the distros, right? It’s not firefox’s job.
- jgraham 5y ago
  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).

the8472 5y ago

> 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.

dblohm7 5y ago
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.
- phendrenad2 5y ago
  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.
  - kaba0 5y ago
    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.
    - phendrenad2 5y ago
      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.
      - viraptor 5y ago
        > 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.
  - dblohm7 5y ago
    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.
kevincox 5y ago
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.
rockdoe 5y ago
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.
- account42 5y ago
  They could have one pristine unused content process and then just fork new ones from that.
kelnos 5y ago
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.
- makomk 5y ago
  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.

phendrenad2 5y ago

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

kaba0 5y ago
You mean the distros, right? It’s not firefox’s job.
jgraham 5y ago
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).