[Webkit-unassigned] [Bug 200967] WebProcess ProcessSwapping problems

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=200967

--- Comment #9 from Carlos Garcia Campos <cgarcia at igalia.com> ---
Instead of disabling page cache we could disable the page suspension in 2.26 to ensure applications can still working without changes. If I understood the code correctly, suspended pages are used only for history navigation. Pages are suspended for 10 seconds, so that if you navigate back to a page that is still suspended the same process and page is used. I think we can live without that optimization for 2.26. I don't see how to provide backwards compatibility here otherwise, because emitting page-created when a page is unsuspended wouldn't work either, because apps assume it's not emitted twice for the same WebKitWebPage. In the case of ephy we would want to emit the PageCreated DBus signal, but not the rest of the things we do in the page created callback. 

In the case of trunk, I think we should add a new signal, and update applications to handle it. I'm still not sure how we could expose it in the api, though.

 - We could add page-attached that would also be emitted after page-created. Then we could split current page-created, and use page-attached to notify the UI process that the injected bundle connection should be used for that page. Apps would use this instead of page created to set the current injected bundle proxy.

 - Or we could expose is-suspended as a property than can be monitored. Apps would need to keep a list of injected bundle proxies for the same web view. When the page is unsuspended, the UI process is notified and the web view sets the unsuspended injected bundle proxy as the current one.

Again, for trunk I don't see any solution that doesn't require to update the applications. We should probably encourage apps not to use custom IPC for the communication from UI process to injected bundle and use webkit_web_view_run_javascript() instead.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190904/ef64b9c0/attachment.html>