I don't know if this is a use case that we want to cover, but I wanted to report it here nonetheless. If a user updates their webkitgtk packages on a running system then any program that is using webkit (evolution, epiphany, etc.) is likely to crash. This is probably due to the fact that at some point there will be running UI, web and/or network processes from different versions of webkit in the same app. I don't know if there's a general solution for this from the webkit side. Detecting the version mismatch and respawning the affected process may mitigate the problem but it probably won't cover all cases and it's maybe not worth the added complexity. So unless you have any better suggestions I think the best solution is to recommend restarting the session / system for a software update.
> Detecting the version mismatch and respawning the affected process may mitigate the problem but it probably won't cover all cases and it's maybe not worth the added complexity. You have it backwards. The UI process can detect the child processes have changed and refuse to start them. This is how other browsers such as Chromium work. Once an update has happened you can't open new websites you need to restart the browser.
We could emit a signal on WebKitWebContext. The application would then have the opportunity to display UI suggesting that the user restart. > Detecting the version mismatch and respawning the affected process may mitigate the problem but it probably won't cover all cases and it's maybe not worth the added complexity. Patrick's right: you'd have to restart the UI process as well, which is impossible, not just the child processes. Another impossible alternative would be to never start new child processes. I would expect WebKit to continue working fine so long as no new processes are started. Here's something that might actually work: we could copy the subprocess binaries into a private location under /run when the UI process starts, before launching anything. If each UI process had its own separate copies of its subprocess binaries, as they existed at the time the UI process was launched, then WebKit would be robust to system upgrades. I don't think that's worth the effort, but it *should* work.
(In reply to Michael Catanzaro from comment #2) > We could emit a signal on WebKitWebContext. The application would then have > the opportunity to display UI suggesting that the user restart. > > > Detecting the version mismatch and respawning the affected process may mitigate the problem but it probably won't cover all cases and it's maybe not worth the added complexity. > > Patrick's right: you'd have to restart the UI process as well, which is > impossible, not just the child processes. Another impossible alternative > would be to never start new child processes. I would expect WebKit to > continue working fine so long as no new processes are started. Exactly. This is why Firefox and Chrom{e,ium} will offer you to restart the whole browser after an upgrade. > Here's something that might actually work: we could copy the subprocess > binaries into a private location under /run when the UI process starts, > before launching anything. If each UI process had its own separate copies of > its subprocess binaries, as they existed at the time the UI process was > launched, then WebKit would be robust to system upgrades. I don't think > that's worth the effort, but it *should* work. I'd say it's not worth it.
(In reply to Michael Catanzaro from comment #2) > We could emit a signal on WebKitWebContext. The application would then have > the opportunity to display UI suggesting that the user restart. Ok, so the question is: is that worth doing, or shall we consider this problem a WONTFIX ?
I think it's worth it, if somebody wants to implement it. I would do it using GFileMonitor. Since file monitors are a precious resource, I wonder if it would suffice to monitor the PKGLIBEXECDIR rather than monitoring individual files.