[Webkit-unassigned] [Bug 243492] [GTK][WPE] Support asynchronously returning values from user script messages

[bugzilla-daemon at webkit.org]

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

--- Comment #1 from Adrian Perez <aperez at igalia.com> ---
In order to maintain API/ABI compatibility we are allowed to:

 - Add new C functions.
 - Add parameters to a C function only if it doesn't cause a leak.
 - Add a return value to a C function returning void only if it doesn't cause a leak.
 - Add/remove modifiers (like “const”), as they are not part of the C ABI.

In all cases we will need a new function that registers a new message
handler *with* async replies enabled. Something like:

  WEBKIT_API void
  webkit_user_content_manager_register_script_message_handler_with_reply (
      WebKitUserContentManager *manager, const char *name, const char *world_name);

The reason to add a “world_name” parameter is that we can allow passing
NULL to use the default, and that way we don't need a second function
that has an “_in_world” suffix in the name.

Calling this new function will also instantiate a ScriptMessageClientGtk,
object (like the existing ones) but will set a flag to indicate that it
supports async replies.


Option 1
--------

We could add a return value and a new parameter to the signature of the
WebKitUserContentManager::script-message-received signal: it would need
to be added at the *end* of the list of parameters; but the conventions
in the API mandate that the userdata pointer is always the last one.

So we cannot really do this.


Option 2
--------

Another option is to add methods to WebKitJavascriptResult that allow
providing the reply, as in:

 webkit_javascript_result_reply (WebKitJavaScriptResult *js_result,
                                 JSCValue               *reply_value,
                                 GError                 *error);

The idea is that one provides a “reply_value” or an “error”, but not both.

Then, we change the return type of the ::script-message-received from
“void” to “gboolean”. The returned value won't be used for the handlers
without reply.

For the handlers that expect a reply, returning TRUE from the signal
handler will mean “the reply will be provided later”, which allows
behaving asynchronously -- we use this same pattern for example in
other signals like WebKitWebView::permission-request.


Option 3
--------

Lastly, we could have a new signal, for example call
it WebKitUserContentManager::script-message (IMO the “-received”
suffix in the old one is redundant) and provide a new helper class,
let's say WebKitUserScriptRequest, with the following methods:

  JSCValue*
  webkit_user_script_request_get_message(WebKitUserScriptRequest *request);

  void
  webkit_user_script_request_reply(WebKitUserScriptRequest *request,
                                   JSCValue *reply_value);

  void
  webkit_user_script_request_error(WebKitUserScriptRequest *request,
                                   GError *error);

Then handlers for the new ::script-message signal would receive an
instance of WebKitUserScriptRequest, which allows accessing the message
passed to the handler from JavaScript, and supports providing a reply.
Signal handler functions would have the following signature:

  gboolean signal_handler(WebKitUserContentManager *content_manager
                          WebKitUserScriptRequest *request,
                          gpointer userdata);

Again, if a handler returns TRUE, that means that the reply will be
done later on, asynchronously.


What to do?
-----------

IMO the best option is number 3. While at it, I would also mark the
existing (old) functions and signal as deprecated: the new functionality
will be a superset of the old one. When a reply is not provided using
webkit_user_script_request_reply() by the signal handler function, we
can return the “undefined” value as the default action.

The other possible one (number 2) would leave us with an uglier API
because it's adding a method to WebKitJavascriptResult which does not
belong in that class, and also changing signatures of existing
functions/signals, while possible in this particular situation, is
quite ugly.

-- 
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/20220803/d65a47fb/attachment.htm>