El mar, 28-06-2016 a las 11:57 +0200, Jay Strict escribió: > On 27.06.2016 14:17, Adrián Pérez de Castro wrote: > > Quoting Carlos Garcia Campos (2016-06-27 08:21:13) > > > Of course, we just need to fully understand the problem and > > > decide how > > > to make it possible. The easiest solution might be to add support > > > for > > > loading JS web extensions. Adri started to work on python web > > > extensions, I don't know if JS support would be very different. > > > See: > > > > > > https://lists.webkit.org/pipermail/webkit-gtk/2015-August/002416. > > > html > > > > > > This would be the ideal solution in my opinion. But we could also > > > add > > > API to the UI process to provide a set of headers to be added to > > > any > > > request, for example, and use that from the web process. This > > > would > > > probably be easier, but we can't add UI process API for every > > > single > > > web extension feature required by JS apps, so adding a way to > > > load JS > > > extensions would be much better. > > I was thinking of changing the semantics of the signal > 'resource-load-started', since there is so much confusion about it. > (Many people expect to be able to connect to this and change the > underlying request. I did expect this, Michael Catanzaro did expect > this > and the stackoverflow answer I linked to did also expect this.)
It's not a matter of changing the semantics, the signal says the load has already started, so it's too late to modify the request. What is very confusing is the documentation: "Emitted when a new resource is going to be loaded. The request parameter contains the WebKitURIRequest that will be sent to the server. You can monitor the load operation by connecting to the different signals of resource." I guess we copy pasted from wk1 documentation, we should update that to make it clear that request has already been sent, not is about to be sent. > Of course, you then would have to find a distinct name, like > 'resource-load-start' or 'resource-load-initialize' and maybe > deprecate > the old signal ... I don't really know. Changing the name doesn't change anything, the notification is sent to the UI process when the request has already been sent. What you want is WebPage::send-request signal that was added exactly for your use case, and it's the replacement of the resource-load-started signal in wk1. Handling this in the UI process would mean that for every single resource loaded by the web process, we would send an sync message from the web process to the ui process to allow the user modify or even block the resource request. That would make the load a lot slower and would block the application. > Such a signal used to exist in WebKitGTK1 [1]. WebKit1 was not multiprocess, the replacement for that signal is WebPage::send-request. > But I could also understand if you say that this breaks too much API. > > > > I do agree with Carlos here, and WebKitGTK+ should provide a way of > > loading > > JavaScript web extensions. As for Python, I have a working proof of > > concept > > C WebExtension which is a shim that itself loads the Python > > extension. You > > can check it here: > > > > https://github.com/aperezdc/webkit2gtk-python-webextension-exampl > > e > > > > (I am aware of a couple of people using the code in there as a > > basis for > > their Python applications which need a web extension, though in the > > longer > > term we will have something similar shipped with WebKitGTK+.) > > > > Having a similar proof-of-concept for JavaScript extensions would > > be great. > > Ideally, it would be great to use JavaScriptCore for that, because > > it is > > part of WebKitGTK+. As tempting as it might be to use GJS, it looks > > like > > sticking to JSC (via Seed, see https://wiki.gnome.org/Projects/Seed > > ) would > > be better to have less dependencies in the case where one wants to > > use > > WebKitGTK+ *without* having GNOME Shell installed. > > Being able to use WebExtensions from all interpreted languages seems > nice. Although, I must admit that it is hard for me to fully > understand > all that you have said. > Would this enable me to use WebExtensions in Gnome shell extensions? Yes. > Furthermore, I have the feeling that for this to fully take off in > the > sense that I can use it in standard Gnome shell extensions is a > matter > of several years. :/ I don't know, we just need someone to write the patch, and I'll be happy to review it. > > > Kind regards, > Jay > > [1] > http://webkitgtk.org/reference/webkitgtk/unstable/webkitgtk-webkitweb > view.html#WebKitWebView-resource-request-starting > -- Carlos Garcia Campos http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3
signature.asc
Description: This is a digitally signed message part
_______________________________________________ webkit-gtk mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-gtk
