In 2018 in a real OS (linux) it shows up along with all the other updates in a central gui for updating your OS that depending on your flavor may notify you of available updates for example by incriminating the number in a tray icon but never forces you to install except when it is convenient for you.

If you install locally. Example downloading the nightly build to a local dir or installing in windows you may receive notifications of a new version when you open it but you can safely dismiss them with one click and update next Thursday if you like. At no point will it decide that its time whether you like it or not like windows update.

> My favorite is prompting me to restart to install an update when I open it.

It's the best they can do. Windows carries a lot of baggage and bad decisions around its OS design. One of them is that when a file has an exclusive lock (eg an .exe file that's running) it can't be deleted. NTFS and Windows Kernel don't implement reference counting like a proper OS.

So Firefox (or any software package with in-place self-update functionality) needs to wait until the application is shut down to perform updates. Firefox team chose to do it before launching the app. They could have done it after closing it. Both approaches have their pros and cons so it's not easy to criticize them either way.

I am not an expert on this, but I believe Chrome downloads a new exe waiting to be copied over when it is launched. The Firefox updater on the other hand is a whole progress bar experience where a lot of things seem to have to happen to perform an update.

This is correct. Chrome handles updates via a completely separate .exe that runs via the Windows Task Scheduler.

I know this because my company pushed out a Group Policy update a while back that removed the ability of users to add/remove scheduled tasks and it broke Chrome updates across the company.

Also, this problem (not being able to patch a running app) is unique to Windows because of its terrible file locking implementation (that are the result of a bad decision made decades ago!). In Linux you'll get Chrome, Chromium, and Firefox updates along with everything else and it won't disrupt your use in the slightest. You can restart the app to apply those updates at your leisure!

Firefox does this too, see Mozilla Maintenance Service.

I believe the problem with Edge is (correct me if I'm wrong) that files that would need to be updated are used by Windows Explorer, so any update would need a restart of the machine.

I thought they pushed Windows 10 and Edge to let go of legacy cruft. This is so year 2000 that app update needs a reboot.

I remember being so excited to try windows ME... and let down so, so, so, so hard.

Today I learned that VMS wasn't a proper OS, because proper OS let processes blindly overwrite files from others.

Unlink with reference counting, not overwrite. This allows the program to "delete" itself but the file remains as an unnamed file on the drive until the last program that references it exits.

If the file name was the last hard link to the file, the file itself is deleted as soon as no program has it open.

Ref: https://en.wikipedia.org/wiki/Unlink_(Unix)

The only problem with IE box model was that they implemented it before the standard got finished (and changed) so it was impossible to fix it without breaking already existing web pages.

The situation is not very different from now with Chrome implementing unfinished proposals.

The problem isn't that Microsoft implemented an unfinished API. It's that they implemented an unfinished API and didn't update it later to reflect the changes.

When new APIs are in development (in a standards body) by all means implement the incomplete/early version in your browser! Just put a warning somewhere for developers that changes will happen and that they should expect to have to update their code along with the standard as each iteration comes out.

Microsoft made a huuuuuuuge mistake by implementing an unfinished API and then refusing to make breaking changes later. Breaking changes are to be expected when you do stuff like this!

Back when MS did this they were still highly arrogant about their position in the browser market and probably still thought they could get away with their usual "embrace and extend" bullshit... Where they decide "the standard" regardless of what any standards body or the rest of the world/community thinks.

I'm not defending MS, but it's also not that they went and intentionally (and suddenly) introduced box-model incompatibilities, that's just not the whole truth.

BTW: I've recently found this MSDN blog with explanations on some of their decisions (https://blogs.msdn.microsoft.com/oldnewthing/)

It's very different with feature flags. Browser prefixes was a nice idea in theory but should have predicted it wouldn't work out.

Coupled with an indiscriminate upgrade policy it is actually reasonable to deprecate features from chrome.

> Changing the box model

Most of the things you said I agree. But honestly the box model is one of these. The additive model standardized by W3C isn't really popular in the web designer crowd. I cut my teeth in an era where W3C and standard compliance were huge things, so I accepted the additive model without question. Nowadays though many designers opt for Microsoft's "broken" box model aka subtractive model through the box-sizing property.

There was nothing "broken" about it. It was just non-standard at the time, but the old standards were wrong, like they were on many matters (floats for layout, for example, was a load of shit).

Floats were just supposed to be used to control text floating around images and other inserts. It was never designed as a general-purpose layout mechanism.

Sure, but that's largely because standards bodies chose not to introduce a general purpose layout mechanism despite it being very clear from 1990s websites that the need existed, and instead focused on deprecating layout elements from HTML and persuading developers CSS was the only valid way to do layout.

CSS layout capabilites is a superset of what is possible with presentational HTML, so deprecating presentational HTML is not really the issue. Many of the crazy float hacks was to achieve layouts like expanding sidebars - the so-called "holy grail layout". But this could be cleanly and easily achieved with display:table. So why didn't people use display:table? Because Internet Explorer did not support it. Microsoft disbanded the IE team and did not develop the browser for many years, but the browser still had a big enough market share that developers had to support it.

Few things to note:

- Edge is (kindof) available on Android. It uses the Chromium engine, but includes bookmark and password syncing with the desktop version.

- Firefox will (depending on platform support) update in the background and notify you to restart (Windows), or it will apply the update at app start (macOS).

They should apply it when the last window is closed (checking the OS is not shutting down).

On Arch Linux, the browser would often crash after the system upgrade installed a newer version of Firefox. I read on their bug tracker that the upgrade prompt was a workaround for this (or at least one reason for it).

Was it due to the upgrade removing files the current version expected to be there?

Similar to how pacman (by default) removes all modules for the current running kernel, during an upgrade?

..which then breaks pretty much everything that relies on dynamic module loading, such as USB.

They should just do it when you close the last window, if the OS is not shutting down.

On Linux, Firefox does not really have a choice. When the system rips out some vital libraries from under you because of an update, you can continue to use the old libraries in processes where they are already loaded. But new processes (i.e. new tabs) will not be able to load the old libraries.

It's similar to how, when you install a kernel update, new devices are not recognized anymore because the loadable kernel modules on disk are for the new kernel version, but you're still running the old kernel version. (There is the workaround employed e.g. by Debian where old kernel modules are left on the disk until they're cleaned up manually, but that opens the "manual cleanup" can of worms.)

> But new processes (i.e. new tabs) will not be able to load the old libraries.

I think it should be possible under Linux. Firefox could pass the old libraries as file descriptors to its child process and and the child could dlopen those through /proc/self/fd/... . Or a more robust mechanism along these lines. But I wouldn't seriously suggest that Firefox should do something like this, restarting Firefox every once in a while is fine.

> It's 2018. The era is office like updates is over.

It's 2018. If you don't want to deal with updates like that, then stop using a shitty OS like windows.