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

[Carlos Garcia Campos]

El mié, 16-10-2019 a las 19:38 +0100, Gavin Smith escribió:
> (please CC me in responses as I am not subscribed to the list)
> 
> 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)

> The DOM access gives programs a way to access information inside the
> HTML pages that are being displayed. Even if it can be done by
> running
> JavaScript, this information needs to come back to the controlling
> program and this would require some kind of protocol for
> communicating
> over a textual channel between the JavaScript and native halves of
> the
> program. I think it is simpler to be able to do everything in C.

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.

> This is for a program to read locally installed HTML documentation.
> See
> 
> https://lists.gnu.org/archive/html/bug-texinfo/2019-10/msg00010.html
> 
> and the earlier thread
> 
> https://lists.gnu.org/archive/html/bug-texinfo/2019-04/msg00042.html
> 
> for more context on what we are trying to achieve.
> 
> 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
> don't think there is any benefit for the multi-thread model for this
> use case.

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

> We could have the slightly bizarre situation of it being easier to do
> processing on the HTML files separately (to do it robustly, with some
> HTML parsing library), than to extract the information from the
> embedded browser engine.
> 
> PS I could only subscribe to this mailing list by moving the date on
> my computer back 5 minutes, otherwise I got a "Please take a few
> seconds to fill out the form before submitting it." message.

Weird...

> _______________________________________________
> webkit-gtk mailing list
> webkit-gtk at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-gtk
> 
-- 
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/20191021/1820c7a7/attachment.bin>