On Thu, Oct 30, 2014 at 9:05 AM, Carlos Garcia Campos wrote: > > No, WebView is the UI process API. > > ... > > If I understood correctly what you want, I think it would be something > like: > > In the web extension you connect to the window-object-cleared signal, > and with the exactly same code you currently has extends the window > object to add renderHTML. In the callback you would need to send a > message to the UI process, using DBus or any other IPC mechanism you > want. > > In the UI process, when the message is received you create a WebView, > connects to load-changed, and loads the HTML using > webkit_web_view_load_html. In the load-changed signal when the load > event is finished, you can call webkit_web_view_get_snpashot to > asynchronously get a cairo image surface with the web view contents > rendered. Now you need to send another message to the web extension with > the results.
Yes, this is exactly what I needed, thank you for such a detailed explanation. > I know it's a bit more complex, because JavaScript is in the WebProcess. > We are about to land a patch that would simplify this, you wouldn't need > to extend the window object nor send an IPC message to the UI process. > Your JavaScript code could do something like > window.webkit.messageHandlers.renderer.postMessage() and the message > would be received in the UI process as a signal with a > WebKitJavaScriptResult object to deserialize. > See https://bugs.webkit.org/show_bug.cgi?id=133730 Wow, patches landed four hours ago, definitely I chose the right time to ask! MessageHandlers look very interesting — Is there a similar mechanism to post messages in the opposite direction from the UI process to listeners registered by the JavaScript code? Or do I still need to use some IPC channel for that? _______________________________________________ webkit-gtk mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-gtk
