[Webkit-unassigned] [Bug 182528] [GTK] WebProcess deadlock loading a web view from decide-policy signal callback

[bugzilla-daemon at webkit.org]

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

--- Comment #3 from Michael Gratton <mike at vee.net> ---
(In reply to Carlos Garcia Campos from comment #1)
> One possible solution could be to make the decision
> before creating the new web view. I guess you are actually canceling the
> load to forward it to the new web view. So you could first call ignore() and
> then create the new web view.

Oh, calling ignore() before invoking the call chain that opens the second web view does indeed also fix the issue, without needing the idle callback. Thanks - that's a much better general solution.

Anyway, yeah it's a somewhat understandable technical limitation once you know what is happening under the hood. So as Michael suggests maybe worth documenting any such possibly blocking signals/calls?


(In reply to Michael Catanzaro from comment #2)
> 
> Why are you using the less-tested and less-robust single secondary process 
> model? Is it to reduce memory overhead? For a complex application like
> Geary, I would recommend the multiple secondary process model.

Because if we were using multiple secondary processes and the user loaded a large conversation, an instance would be spawned for every message at once, which seems like it could be kind of slow and yeah, memory intensive, but also lead to a janky user experience. We could delay creating web views until the user expanded the bodies (we should probably be doing this anyway), but then you still have the potential need to launch a bunch if the conversation has a number of starred or unread messages (which are expanded by default), or one for almost every message anyway if the user searches for a common word like "and", which would cause most of the message bodies to be expanded at once.

Conversations in the order of 10's of messages aren't uncommon, and 100+ are possible, and Ephy's general unresponsiveness when restoring a session with even something like 10-20 tabs under the multi-process model put me off it.

Maybe just consider me a tester for the single-shared-process model? :)

-- 
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/20180207/f1041daf/attachment.html>