4 ms·
From what I've heard (haven't done this myself yet) if you install Firefox manually instead of through a package manager, it has an internal update mechanism th
by Izkata 4y ago
From what I've heard (haven't done this myself yet) if you install Firefox manually instead of through a package manager, it has an internal update mechanism that doesn't trigger the "please restart" page. That page is for when a package manager swaps files out from under it, while the internal mechanism waits for you to restart.
- deleted 4y ago[deleted]
- rascul 4y ago> From what I've heard (haven't done this myself yet) if you install Firefox manually instead of through a package manager, it has an internal update mechanism that doesn't trigger the "please restart" page. I install Firefox in such a manner and can confirm the behavior is what you have heard. I've never seen the "please restart" page.
- greatgib 4y agoI hate Snap, but from what I experienced, I also don't think that the problem is related to it but some shitty logic in Firefox. Regarding the "excuse" that it is the package manager that updated the Firefox in background, I saw it repeated a lot of time to deflect the blame, but it is totally not true in my opinion. On my system, I don't allow automatic updates. I have the notification when updates are available, but the system/packages are never updated without me doing it. And still, I noticed multiple times that Firefox breaks suddenly, like that, when nothing was updated on my system for some weeks and everything was working fine.
- Izkata 4y agoUbuntu has an additional system called unattended-upgrades that does security updates in the background without any user interaction. At least in Ubuntu 18.04, pre-snap Firefox is included in it.
- greatgib 4y agoIt is clearly not. On these occasions I have also checked the logs (apt,...) to be sure that nothing was updated in a very long time.
- Izkata 4y agoIt wouldn't be in apt's log, it would be in the unattended-upgrades log. And I can say that when I removed Firefox from its config, it stopped happening to me.
- TillE 4y agoI have never seen anyone mention this issue on macOS or Windows. It's definitely a Linux package manager thing, not part of Firefox's own update process.
- bmicraft 4y agoI can't comment on Ubuntu, maybe they do automatic upgrades in the background and you don't know about them. For me on arch Firefox has shown the "Need to restart" page every time I have updated it's package while running and not a single other time.
- semi-extrinsic 4y agoOn Arch Linux the Firefox installed via the package manager has never auto-updated and never shown this "please restart" page. But probably the official packaging on Arch resembles a manual install on Ubuntu.
- demurgos 4y agoYou may have been lucky or have some specific config or workflow that made you avoid this issue. I'm using a regular Arch installation with Firefox and Pacman. The "please restart" page appears regularly; I just had it yesterday. This occurs when running `pacman -Syu` in some background terminal while Firefox is active.
- easygenes 4y agoIsn’t that expected behavior? Solution: don’t update Firefox while you’re running it. [1] 1: https://wiki.archlinux.org/title/Pacman#Skip_package_from_being_upgraded
- demurgos 4y agoYes, it's 100% normal; and it doesn't really bother me personally. The "please restart" page only appears when opening a new tab (so the disruption is minimal). I never lost any work because of this so it's just a minor inconvenience. I was sharing my experience to illustrate that Arch does not have any protection against this problem _by default_. The post I was replying to was comparing Arch's package to a manual installation.
- ravel-bar-foo 4y ago> The "please restart" page only appears when opening a new tab (so the disruption is minimal). I usually open a new tab when I want to do something in that new tab, which makes the disruption very annoying. (As far as I remember, it also blocks loading of new pages in existing tabs thereafter so the disruption is total.) Then during the restart it loses all info in private tabs.
- AnIdiotOnTheNet 4y agoAlso seems to work that way for the FlatPak version, for what it is worth. I also have never seen the please restart page.
- d110af5ccf 4y agoThe weird thing is that the restart doesn't (usually?) seem to be necessary for it to function, only for you to receive the underlying security update. I learned this because there's a bug where if you have multiple profiles running simultaneously only the main one shows the restart screen. When I found this out it really pissed me off so I tried to figure out where the restart screen showed up in the source code so I could patch it out. But I'm not familiar with the code base and left off after a bit of digging because I really can't justify the time spent. In reality I end up holding back Firefox updates with my package manager until I'm ready to restart it. In the end I will thwart developers trying to dictate things to me. The software on my computer works for me, not the other way around. A lot of developers seem to be far too arrogant and forget this basic fact.
- iggldiggl 4y agoThe problem is that with the way multi-process browsing works there is a long-lived parent process, which is only shut down when you fully close the browser, and there are a number of potentially shorter-lived child process that handle the actual browsing and rendering of web content. So at any point the browser needs to be able to potentially launch a new child process if you open a new tab, or even just browse to a different website on a different domain (origin) – which thanks to site isolation nowadays requires a separate process, too, unless perhaps a page from the same origin is already open in a different tab. If thanks to an ignorant update service the browser's binaries have been swapped out from underneath it, that now means that you've got an "old" parent process suddenly talking to a "new" child process, which isn't an officially supported configuration. If you're lucky, there were no breaking changes within the browser and things might work anyway, but there are no guarantees that things always turn out that way, since the API between parent and child processes is a purely internal one and browser developers feel free to rejigger it any time they need to. While in principle you could try to develop the browser in such a way that a certain amount of forwards/backwards compatibility is preserved between an older parent process talking to an updated child process, I presume that doing so would also significantly complicate development on anything that touches the parent/child process interface, and you could equally claim that it's Linux's package manager behaviour regarding updates (just swap out the files underneath a running process) that's broken.