[Webkit-unassigned] [Bug 256335] New: [GLib] Audit and fix incorrect use of (closure) in WebKitGTK

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu May 4 14:49:33 PDT 2023


https://bugs.webkit.org/show_bug.cgi?id=256335

            Bug ID: 256335
           Summary: [GLib] Audit and fix incorrect use of (closure) in
                    WebKitGTK
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKitGTK
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: mcatanzaro at redhat.com
                CC: bugs-noreply at webkitgtk.org

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20230504/631093c1/attachment.htm>


More information about the webkit-unassigned mailing list