Re: [webkit-gtk] Future of direct DOM access in WebKitGTK

[Gavin Smith]

On Mon, Oct 21, 2019 at 10:12 AM Carlos Garcia Campos
<address@hidden> wrote:
>
> El mié, 16-10-2019 a las 19:38 +0100, Gavin Smith escribió:
> > I'd like to ask what is the future of the DOM access functions that
> > were deprecated in WebKitGTK+ 2.22.0. The documentation advises using
> > a "JavaScriptCore" API instead.
> >
> > https://webkitgtk.org/2018/09/03/webkitgtk2.22.0-released.html
>
> Yes, current DOM bindings API marked as deprecated will be removed in
> the next binary version bump.
>
> > I think it would be unfortunate if this functionality were removed.
>
> The functionality is not removed, everything you can do with the DOM
> API can be done with JSC
> (https://webkitgtk.org/reference/jsc-glib/stable/index.html)

That manual doesn't explain how to use JavaScriptCore to do this. For
example, there is a type called JSCContext, representing the
"JavaScript execution context", but it doesn't explain how to get the
reference for a webpage being displayed in a WebKitWebView.

https://webkitgtk.org/reference/webkit2gtk/stable/WebKitWebView.html
and https://webkitgtk.org/reference/webkit2gtk/stable/WebKitWebContext.html
make no reference to "JSCContext".

> I'm not sure I understand. You can use the JSC API from C like you do
> with the DOM API. You can take a look at epiphany code to see how it
> uses the JSC API to access the DOM.

I downloaded a ZIP file of the source code for epiphany from
https://github.com/GNOME/epiphany and grepped for the string "JSC" in
the source files. It appeared to be using a function
"webkit_frame_get_js_context" to get the JSCContext object, documented
here: 
https://webkitgtk.org/reference/webkit2gtk/stable/WebKitFrame.html#webkit-frame-get-js-context.
This is part of the "web extension" API.

It is probably possible to do but it would require looking over all
the documentation to find the relevant information and possibly
looking at the epiphany source code as well to try to understand how
epiphany does it.

> > As an aside, it would be even better if you could have direct DOM
> > access in the main thread, as was the case with WebKitGTK version 1.
>
> I guess you mean, from the UI process, instead of the main thread. The
> DOM is in the web process, and that can't be changed.

I wonder if JSC could prevent the need for an extension module in the
web process. For example, could you get a JSCValue[1] in the UI
process representing a DOM element for a page inside a web process?

[1] https://webkitgtk.org/reference/jsc-glib/stable/JSCValue.html

This would simplify the architecture of the program from

UI process <-------> Web process <--------> JavaScript context

where there are two levels of message passing to just

UI process <-------> JavaScript context

There is already some provision for executing JavaScript from the UI
process[1] but I am not sure if it is enough.

[1] 
https://webkitgtk.org/reference/webkit2gtk/stable/WebKitWebView.html#webkit-web-view-run-javascript

> Yes, probably not for this use case, but the multi-process architecture
> is the only one right now, and we can't maintain both. Btw, regarding
> the communication between UI and web processes, we have recently landed
> a patch to add a user message API, so you won't have to use your socket
> based one. See https://bugs.webkit.org/show_bug.cgi?id=202847

That would be an improvement. The socket method currently used puts a
limit on the size of the message and converts non-linear structures to
and from a linear text format using an ad-hoc protocol. This probably
accounts for 40%-50% of the complexity of the program. It would
certainly help to be able to send richer data structures of arbitrary
size.