Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 56d72f8919459362e429e89f783abb33e32d8709
https://github.com/WebKit/WebKit/commit/56d72f8919459362e429e89f783abb33e32d8709
Author: Michael Catanzaro <[email protected]>
Date: 2023-05-05 (Fri, 05 May 2023)
Changed paths:
M Source/JavaScriptCore/API/glib/JSCClass.cpp
M Source/JavaScriptCore/API/glib/JSCContext.cpp
M Source/JavaScriptCore/API/glib/JSCValue.cpp
M Source/WebKit/UIProcess/API/glib/WebKitCookieManager.cpp
M Source/WebKit/UIProcess/API/glib/WebKitFaviconDatabase.cpp
M Source/WebKit/UIProcess/API/glib/WebKitNetworkSession.cpp
M Source/WebKit/UIProcess/API/glib/WebKitUserContentFilterStore.cpp
M Source/WebKit/UIProcess/API/glib/WebKitWebContext.cpp
M Source/WebKit/UIProcess/API/glib/WebKitWebResource.cpp
M Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp
M Source/WebKit/UIProcess/API/glib/WebKitWebsiteDataManager.cpp
M Source/WebKit/WebProcess/InjectedBundle/API/glib/WebKitWebExtension.cpp
M Source/WebKit/WebProcess/InjectedBundle/API/glib/WebKitWebPage.cpp
M
Source/WebKit/WebProcess/InjectedBundle/API/glib/WebKitWebProcessExtension.cpp
Log Message:
-----------
[GLib] Audit and fix incorrect use of (closure) in WebKit
https://bugs.webkit.org/show_bug.cgi?id=256335
Reviewed by Adrian Perez de Castro.
Following Emmanuele's guidance in
https://www.bassi.io/articles/2023/02/20/bindable-api-2023/ I have audited our
use of (closure) annotations in WebKit and found they are all incorrect. Unary
(closure) is only allowed on function typedefs; in function declarations an
argument is always required, e.g. (closure user_data). But (closure user_data)
is actually default, so most of our annotations can actually be removed.
It looks like this was not causing many problems in practice. For example,
let's look at the callback parameter to jsc_class_add_constructor generated
*before* this patch:
<parameter name="callback"
transfer-ownership="none"
scope="notified"
closure="2"
destroy="3">
<doc xml:space="preserve"
filename="Source/JavaScriptCore/API/glib/JSCClass.cpp"
line="569">a #GCallback to be called to create an instance of
@jsc_class</doc>
<type name="GObject.Callback" c:type="GCallback"/>
</parameter>
This already looks fine: it knows the closure parameter comes right after
callback, which is the correct order. So even though Emmanuele says this use of
unary closure was incorrect, it wasn't causing problems in practice.
Looking through the generated JavaScriptCore-6.0.gir, this results in gir
changes for only jsc_value_new_array_buffer and
jsc_value_new_typed_array_with_buffer, where the closure parameter was
previously not detected, which is now fixed. I don't think this resulted in any
changes to WebKit-6.0.gir.
I've also fixed WPE's webkit_web_view_add_frame_displayed_callback() where the
callback parameter defaulted to (scope call), causing it to be valid only for
the duration of the function call.
* Source/JavaScriptCore/API/glib/JSCClass.cpp:
* Source/JavaScriptCore/API/glib/JSCContext.cpp:
* Source/JavaScriptCore/API/glib/JSCValue.cpp:
* Source/WebKit/UIProcess/API/glib/WebKitCookieManager.cpp:
* Source/WebKit/UIProcess/API/glib/WebKitFaviconDatabase.cpp:
* Source/WebKit/UIProcess/API/glib/WebKitNetworkSession.cpp:
* Source/WebKit/UIProcess/API/glib/WebKitUserContentFilterStore.cpp:
* Source/WebKit/UIProcess/API/glib/WebKitWebContext.cpp:
* Source/WebKit/UIProcess/API/glib/WebKitWebResource.cpp:
* Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp:
* Source/WebKit/UIProcess/API/glib/WebKitWebsiteDataManager.cpp:
* Source/WebKit/WebProcess/InjectedBundle/API/glib/WebKitWebExtension.cpp:
* Source/WebKit/WebProcess/InjectedBundle/API/glib/WebKitWebPage.cpp:
*
Source/WebKit/WebProcess/InjectedBundle/API/glib/WebKitWebProcessExtension.cpp:
Canonical link: https://commits.webkit.org/263714@main
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
