[webkit-gtk] webextensions, iframes and main gui process

[Gaute Hope]

Michael Gratton writes on June 23, 2018 8:22:
> On Thu, Jun 21, 2018 at 11:47 PM, Gaute Hope <eg at gaute.vetsj.com> wrote:
>> Do you have any suggestions for how I could design or circumvent this?
> 
> Everything involving I/O that needs to be done on the main loop should 
> be done asynchronously. That's precisely why GLib-based libs have such 
> good support for async operations: To avoid blocking the GUI.
> 
> In particular for WebKitGTK, if the data you need to exchange between 
> the GUI process and WebExtension can be trivially formatted and 
> re-parsed (GVariant helps a lot with that), then consider using 
> webkit_web_view_run_javascript() instead of your own custom protobuf 
> IPC.
> 
> If the data you need to load from the GUI process is large enough, 
> maybe consider registering a custom URI scheme handler using 
> webkit_web_context_register_uri_scheme(), then let WebKitGTK handle 
> getting the data to the WebProcess asynchronously for you.
> 
> If neither of those are a good fit, write an async protobuf wrapper 
> using a background thread, so that when it blocks, it doesn't block the 
> GUI as well.
> 
> Geary uses the first two of these approaches with WebKitGTK, and the 
> last approach for interacting asynchronously with SQLite, and they all 
> work quite well.

Hi Mike,

thanks for your answer. As you might have noticed I have found a lot of 
inspiration in Geary when it comes to message rendering - thanks! I 
noticed that I could use the set_inner_html() on the body from 
iframe_get_content_document() without generating a request. This solves 
my problem.

The necessicity to do all DOM manipulation on the main WE-thread 
(sync'ed) and the interactivity between the webpage and the GUI allows 
my design to become a lot simpler if I can do sync'ed requests between 
my GUI thread and the WE-thread. Async-options would require me to keep 
blocking user-events and making my GUI inactive when I am waiting for a 
request to finish. I was hoping to avoid this since it would be really 
hard to reliably guard against this. Especially since external events / 
timers also need to be blocked untill the request is done. The last 
option is what I am doing now (I just choose to do most things sync'ed).

- gaute

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.webkit.org/pipermail/webkit-gtk/attachments/20180626/51383e77/attachment.bin>