Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The 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.



The 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: