When there's an HTML code snippet like this one: <svg width='16' height='16'> <use xlink:href='https://thisweek.gnome.org/images/icons.svg#link'></use> </svg> the WebKitGTK ignores the WebKitWebPage::send-request callback on the extension side and immediately claims: mail://xxx/yyy/xzz?....:55:145: CONSOLE SECURITY ERROR Unsafe attempt to load URL https://thisweek.gnome.org/images/icons.svg from origin mail://xxx. Domains, protocols and ports must match. The URL from the `use` tag should be processed by the WebKitWebPage::send-request first, as is done for other URL-s, like for example with the <img src=...>. This can be a security problem for use cases where the WebKitWebPage::send-request callback is supposed to filter what should be processed in what way (like manual download, which does not involve WebKitGTK internals).
I'm not sure whether this is a bug. The request is blocked because it's illegal. Then send-request is not emitted because no request is going to be sent. But if the signal is emitted for <img src=...> in the same situation, that's certainly inconsistent and bad.
> But if the signal is emitted for <img src=...> in the same situation, that's certainly inconsistent and bad. Right, it is emitted for the <img>, <link>, <video><source> and possibly some other, only not for this one. Before you claim the current behaviour is inconsistent, but otherwise correct, I do not think so, it's not correct, because if the app wants to have under control which remote resources will be loaded from the internet and which not, then you cannot rule some URL-s out before you give a chance to the app to "redirect" the URI to the place the app can work with. You know, not every WebKitGTK usage is a world wide web page view.
Bug #248470 contains a test message with a lot of preload/prefetech/what not constructs in the HTML code, which all of them should be processed by the WebKitWebPage::send-request first, from my point of view. I forgot to add, this is with webkit2gtk4.1-2.38.0-3.fc37.x86_64