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

[Carlos Garcia Campos]

El vie, 25-10-2019 a las 14:02 +0100, Gavin Smith escribió:
> On Mon, Oct 21, 2019 at 10:12 AM Carlos Garcia Campos
> <cgarcia at igalia.com> 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".

The JavaScript runs in the web process, so it's no possible to get the
JSCContext from the UI process, you need to use 

https://webkitgtk.org/reference/webkit2gtk/stable/WebKitFrame.html#webkit-frame-get-js-context

> > 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.

Exactly, because both the JavaScript and the DOM tree are in the web
process.

> 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

No, it's not possible.

> 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

It depends on what you need, it might be enough, but not everything can
be serialized and sent from web to UI process.

> > 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.
> 
-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <http://lists.webkit.org/pipermail/webkit-gtk/attachments/20191028/b67eccad/attachment.bin>