[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Carlos Garcia Campos
Subject: Re: [webkit-gtk] Future of direct DOM access in WebKitGTK
Date: Mon, 21 Oct 2019 11:12:19 +0200
User-agent: Evolution 3.34.1-2+b1

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 

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


> _______________________________________________
> webkit-gtk mailing list
> address@hidden
> https://lists.webkit.org/mailman/listinfo/webkit-gtk
Carlos Garcia Campos

Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]