Oh cool! Now that I think of it I haven't seen the crash window in quite some time. Well done!
Now if I could only disable Ctrl+Q and prevent it from asking for a restart after update...
Now if I could only disable Ctrl+Q and 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.
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.
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.
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.
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.
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.
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.
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).
Good news! =)
Set browser.quitShortcut.disabled in about:config
That's awesome, just did this. But apparently you need to restart Firefox in order to apply the change. (Learned it the hard way)
But otherwise, FF has been really stable for years now
It's nothing that would make me stop using it, just an annoyance that I wish I didn't have to deal with on a semi-regular basis.
But I agree with you, I can't remember when was the last time I had a crash before these!