Another problem is that HTTP requests are probably not the only way
that network usage can happen, e.g. WebRTC or WebSockets presumably
won't go through send-request. Not sure what to do about that.
On Wed, Aug 2 2023 at 06:46:04 PM +0000, Albrecht Dreß
<albrecht.dr...@posteo.de> wrote:
Please excuse my imprecise description – I *do* actually catch this
signal in my extension. The handler is connected in the
WebExtension::page-created callback via
g_signal_connect(web_page, "send-request",
G_CALLBACK(send_request_cb), NULL);
and the latter callback changes the request URI to
webkit_uri_request_set_uri(request, "about:blank");
It's probably better to return TRUE to block the request.
unless the uri is already “about:blank” or starts with “cid:”
or “data:”. A debug message indicates that the signal is caught,
and tcpdump doesn't show the http request, so I /think/ this part
works as expected.
To me, this behavior looks as if the WebKitWebPage::send-request
signal is fired only /after/ the connect() to the target host, but
before the send(), which would perfectly explain my observations.
That would be really weird and certainly not how it's supposed to work,
but I've seen stranger bugs....
If that doesn't work, it's probably a bug.
I see… so I should create a bug report in bugzilla?
Yes, if the problem still occurs after changing your code to return
TRUE (likely), then please do. The simpler your reproducer, the better
chance of it getting fixed.
Michael
_______________________________________________
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk
