News for hackers. Stuff that matters.
[dead]
Re:Retrospective and technical details on the recent Firefox... by kevingadd on Wednesday February 02, 2022 @04:46AM (#30175561)
Does Firefox force updates on your configuration? On Windows it's opt-in for me. I know Android will forcibly update any app (including Firefox) while you're using it, but you can shut that off system-wide.
Re:Retrospective and technical details on the recent Firefox... by joshgev on Wednesday February 02, 2022 @04:58AM (#30175647)
The default is that it forces a restart when a new update has been downloaded, which has been a frustration for me as apparently it has been for the parent.

Apparently this can be changed by requesting that FF only install updates with explicit consent[1]. I'd think the best way would be to install anything that's available locally when the browser starts without forcing a restart.

[1] https://superuser.com/questions/1451210/how-can-i-make-firef...

Re:Retrospective and technical details on the recent Firefox... by Vinnl on Wednesday February 02, 2022 @05:35AM (#30175886)
Are you using Linux, by any chance? IIRC, the issue here is that the update is done by your package manager, changing Firefox's files out from under them. If you use the direct download from Mozilla, it shouldn't be as disruptive.

I still hope a fix or workaround to this can be found, but knowing why something is the cause makes it easier to accept, at least for me :)

Re:Retrospective and technical details on the recent Firefox... by Nextgrid on Wednesday February 02, 2022 @05:05AM (#30175701)
What pisses me off is less about the update itself (they're typically unnoticeable) but the constant nags and "what's new" crap that opens up after the update. Firefox is more hostile than a lot of paid, proprietary software in this regard.
Re:Retrospective and technical details on the recent Firefox... by brimble on Wednesday February 02, 2022 @01:57PM (#30182211)
This. That crap is significantly more disruptive and irritating that the actual paid ads in old-school free Opera (the largest feature-comparable browser when FF/Phoenix/Firebird first launched).
Re:Retrospective and technical details on the recent Firefox... by alexb_ on Wednesday February 02, 2022 @05:34AM (#30175875)
Happens to me often. I'll be browsing and then suddenly I am told that before I can view the next webpage I MUST restart. Giant PITA if I have a ton of private windows open, as none of those are coming back.
Re:Retrospective and technical details on the recent Firefox... by foxfluff on Wednesday February 02, 2022 @05:48AM (#30175969)
It's not firefox, it's your distro.
Re:Retrospective and technical details on the recent Firefox... by account42 on Wednesday February 02, 2022 @08:07AM (#30176946)
The update might be started by the distro in this case, but there is no reason that Firefox cannot just keep an fd on the resource files open and use that instead of the updated files. Either that or keep things compatible so it can use the new files. Not being able to use the browser after an update is inexcusable.
Re:Retrospective and technical details on the recent Firefox... by foxfluff on Wednesday February 02, 2022 @10:42AM (#30179117)
> there is no reason that Firefox cannot just keep an fd on the resource files open and use that instead of the updated files

If you check what processes you've running, you'll see that firefox has many of them. I'm not going to grep the sources but I believe the ones with the "-contentproc" flag are started with an exec call as needed, and I'm not aware of an exec that works with fds. It requires a path, it executes the binary at that path, and that binary in turn loads a bunch of files it needs. It's all going to blow up if your parent and child processes are running different versions of the program.

Keeping parts of a program compatible with arbitrary versions of other parts of the same program is virtually impossible. Go ahead, checkout 50% of your files from some random version of your project thousands of commits ago while keeping the rest at master, and see if it still compiles and runs correctly.

Re:Retrospective and technical details on the recent Firefox... by account42 on Thursday February 03, 2022 @03:18AM (#30189997)
> If you check what processes you've running, you'll see that firefox has many of them. I'm not going to grep the sources but I believe the ones with the "-contentproc" flag are started with an exec call as needed, and I'm not aware of an exec that works with fds. It requires a path, it executes the binary at that path, and that binary in turn loads a bunch of files it needs. It's all going to blow up if your parent and child processes are running different versions of the program.

That firefox is set up in a way that does not work when replacing the files while running does not meat that it cannot be setup differently. For example you could have one process paused after loading all needed libraries and opening all resource archives and then just fork from that.

NB: You can actually execve the original executable under Linux via /proc/self/exe - while it behaves somewhat like a symlink to e.g. show the original path under ls / readlink, reading from it behaves like a hardlink to the original inode. This does not solve shared libraries however (but does Firefox really need to link its own libraries dynamically?) or resources (you could sendfd them to the new process if you really wanted to go with exec).

> Keeping parts of a program compatible with arbitrary versions of other parts of the same program is virtually impossible. Go ahead, checkout 50% of your files from some random version of your project thousands of commits ago while keeping the rest at master, and see if it still compiles and runs correctly.

The most sensible solution would be to keep all parts in sync, which is possible even if the copies on the filesystem changed. However, you could also have a stable API between the browser binary and the javascript parts if you wanted - that is a far cry from mixing arbitrary source files.

Keep in mind that browsers have become more like a mini-OS and should not get away with behavior common in normal applications but instead should provide stability guarantees more like an OS. And you definitely don't need to reboot because the kernel has been updated on the filesystem.

Re:Retrospective and technical details on the recent Firefox... by foxfluff on Thursday February 03, 2022 @04:38AM (#30190531)
> For example you could have one process paused after loading all needed libraries and opening all resource archives and then just fork from that.

Plausible I guess, but also seems like a lot of effort to work around broken distros. Actually calling exec has tangible benefits too, e.g. it allows each process to have its address space randomized.

> However, you could also have a stable API between the browser binary and the javascript parts if you wanted - that is a far cry from mixing arbitrary source files.

Yes but the problem here is stable API and ABI between the browser binary and.. the browser binary. IPC within a binary is hardly ever written assuming a stable ABI, it'll just constrain the project way too much.

> And you definitely don't need to reboot because the kernel has been updated on the filesystem.

I feel like the kernel isn't really a fair comparison since it's relatively self-contained and you generally don't have multiple instances of the kernel talking to each other using IPC.

But go ahead, update your modules and see if you can still load them on your old kernel without rebooting. No, you can't. Same problem.

Unfortunately OSes today tend to have many dynamically loaded parts that require restarts if you want to keep everything working after updates.

Re:Retrospective and technical details on the recent Firefox... by vvillena on Wednesday February 02, 2022 @12:34PM (#30180854)
AFAIK Chrome behaves the same. You can't update a browser cleanly while it is running. In Windows is is handled correctly because both browsers are updated in the background when the browser is closed, but in Linux-style environments this work is done by the package manager. When the package manager stomps over a running instance of Firefox, the old behavior was to crash. At least, now Firefox can detect what happened and keep the active tabs running while instructing you to please restart the browser.

Regarding private tabs, one workaround would be to store the whole window as a bookmark folder (right click on empty tab area, select all tabs, store as bookmarks).

Re:Retrospective and technical details on the recent Firefox... by account42 on Thursday February 03, 2022 @03:21AM (#30190021)
The package manager does not stomp over the running instance but only replaces the files. The original files even remain on the disc (but without any name) as long as they are open. It is firefox that is designed to have to re-open those files during runtime - but that is not inherently required. Before Firefox went multi-process it handled package updates just fine and there is no technical reason why it can't still do that.
Re:Retrospective and technical details on the recent Firefox... by rockdoe on Thursday February 03, 2022 @04:25AM (#30190456)
>Before Firefox went multi-process it handled package updates just fine

No, the problem was just less common and things randomly stopped working or crashed instead of getting the warning page.

In theory you can design the browser so it keeps all files open and passes down the handles, but I imagine it's a mess to do that in practice, especially as Firefox is still somewhat configurable.

Re:Retrospective and technical details on the recent Firefox... by skinkestek on Wednesday February 02, 2022 @07:57AM (#30176853)
Annoying indeed but at least on my machines I can always get them back manually if they don't show up automatically by going to the history menu and choose "Restore Previous Session". Hopefully this should work everywhere.

(Note: I'm trying to help, not place blame here. I won't blame anyone for not being aware of every power user trick but I hope to help more people become power users. Please do ask questions about Firefox, even if I'm moving to LibreWolf I still wish Firefox well and think many would be better off using them but just aren't aware : )

Re:Retrospective and technical details on the recent Firefox... by alexb_ on Thursday February 03, 2022 @06:12AM (#30191047)
That does not work for Private Windows, which I use often.
Re:Retrospective and technical details on the recent Firefox... by skinkestek on Thursday February 03, 2022 @09:29AM (#30192818)
I see.

I only use those for specific applications (mostly testing actually).

Re:Retrospective and technical details on the recent Firefox... by account42 on Wednesday February 02, 2022 @08:04AM (#30176921)
On Windows it will nag everytime you start the browser even if auto-updates are disabled.