4 ms·

It's explained here pretty well: https://bugzilla.mozilla.org/show_bug.cgi?id=1492023 https://bugzilla.mozilla.org/show_bug.cgi?id=1492023 My reading is that i

by duped 4y ago

It's explained here pretty well: https://bugzilla.mozilla.org/show_bug.cgi?id=1492023 https://bugzilla.mozilla.org/show_bug.cgi?id=1492023 My reading is that if your package manager updates FF on disk while it's running, it can no longer guarantee that new tabs can be created safely, since creating a tab requires spawning a child process and the parent was created with an executable that no longer exists/knows anything about the executable it needs to use when spawning. It is super annoying and I feel like there are some obvious fixes. I'm also not 100% sure why it only happens on Linux (it updates fine on Windows and MacOS while running right?)

cprecioso 4y ago
My Microsoft Edge on macOS breaks when updates are applied (through my company's 3rd party updater). New tabs just go blank.
deleted 4y ago
[deleted]
AndrewDucker 4y ago
On Windows it downloads the updater in the background and then executes it when you next restart Firefox. (At least, as far as I can tell)
- masklinn 4y ago
  Yes, but that's because it's updated by firefox itself. If you install, say, FDE directly on linux, you'll get the same behaviour. But if you use the distro's package manager then I don't think there's a viable workflow for it, as the package manager doesn't have hooks into process management. The package manager would probably have to be subsumed by systemd for that to even be feasible.
Saris 4y ago
On windows it just doesn't do the update until the browser is closed. It's odd that they don't have the same behavior on linux.
- Izkata 4y ago
  More specifically, Firefox is updating itself in that situation so it knows not to do anything until startup/shutdown. When the you-have-to-restart tab appears, it's because Firefox didn't do the update, something external on linux (apt or snap or something) did it in a way Firefox can't handle.
- duped 4y ago
  On Windows applications control their updates, on Linux distros the updates can be triggered externally by the package manager. Or at least, you get an error if you try and modify an executable that is currently being used by a process on Windows.
  - Saris 4y ago
    Hmm, in that case it seems like the package manager should stage the new update and wait for the process to end before doing the update. But I suppose linux is generally geared towards servers, where that isn't an issue.
- hcs 4y ago
  You can get that behavior if you install Firefox from a tar [1], Firefox will then manage its own updates the same as on Windows (though the user running Firefox will need to have permissions to modify the files, which may be risky). But if you install it through apt or some such package manager, the PM is doing the updates, and it doesn't take into account that Firefox is running. [1] http://archive.mozilla.org/pub/firefox/releases/latest/README.txt http://archive.mozilla.org/pub/firefox/releases/latest/READM... has instructions for getting a release tar.
- AnIdiotOnTheNet 4y ago
  Pretty sure that's exactly how it works in the FlatPak version.
- tinus_hn 4y ago
  Not an excuse but that wouldn’t work on a multi-user system of course. The solution is to version the files and keep the old versions until the processes are closed. As Windows enforces because it doesn’t allow you to delete files that are in use.
ilyt 4y ago
From what I can see the bug is about packages, not snaps Package is multiple files app needs replaced, so you have old app getting the files replaced under it during upgrade, that's why restart is needed. In case of snap there is layer between, the "snap" is just a blob that is mounted by a daemon that then runs app off it. If you just move/delete old snap the daemon should just be accessing old one till the app stops

by duped 4y ago

cprecioso 4y ago

My Microsoft Edge on macOS breaks when updates are applied (through my company's 3rd party updater). New tabs just go blank.

deleted 4y ago

[deleted]

AndrewDucker 4y ago

On Windows it downloads the updater in the background and then executes it when you next restart Firefox. (At least, as far as I can tell)

masklinn 4y ago
Yes, but that's because it's updated by firefox itself. If you install, say, FDE directly on linux, you'll get the same behaviour. But if you use the distro's package manager then I don't think there's a viable workflow for it, as the package manager doesn't have hooks into process management. The package manager would probably have to be subsumed by systemd for that to even be feasible.

Saris 4y ago

On windows it just doesn't do the update until the browser is closed. It's odd that they don't have the same behavior on linux.

Izkata 4y ago
More specifically, Firefox is updating itself in that situation so it knows not to do anything until startup/shutdown. When the you-have-to-restart tab appears, it's because Firefox didn't do the update, something external on linux (apt or snap or something) did it in a way Firefox can't handle.
duped 4y ago
On Windows applications control their updates, on Linux distros the updates can be triggered externally by the package manager. Or at least, you get an error if you try and modify an executable that is currently being used by a process on Windows.
- Saris 4y ago
  Hmm, in that case it seems like the package manager should stage the new update and wait for the process to end before doing the update. But I suppose linux is generally geared towards servers, where that isn't an issue.
hcs 4y ago
You can get that behavior if you install Firefox from a tar [1], Firefox will then manage its own updates the same as on Windows (though the user running Firefox will need to have permissions to modify the files, which may be risky). But if you install it through apt or some such package manager, the PM is doing the updates, and it doesn't take into account that Firefox is running. [1] http://archive.mozilla.org/pub/firefox/releases/latest/README.txt http://archive.mozilla.org/pub/firefox/releases/latest/READM... has instructions for getting a release tar.
AnIdiotOnTheNet 4y ago
Pretty sure that's exactly how it works in the FlatPak version.
tinus_hn 4y ago
Not an excuse but that wouldn’t work on a multi-user system of course. The solution is to version the files and keep the old versions until the processes are closed. As Windows enforces because it doesn’t allow you to delete files that are in use.

ilyt 4y ago

From what I can see the bug is about packages, not snaps Package is multiple files app needs replaced, so you have old app getting the files replaced under it during upgrade, that's why restart is needed. In case of snap there is layer between, the "snap" is just a blob that is mounted by a daemon that then runs app off it. If you just move/delete old snap the daemon should just be accessing old one till the app stops