[Webkit-unassigned] [Bug 204839] [GTK] webkit_user_content_manager_register_script_message_handler failing with shared process

[bugzilla-daemon at webkit.org]

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

--- Comment #2 from Michael Catanzaro <mcatanzaro at gnome.org> ---
(In reply to Michael Gratton from comment #0)
> However when calling
> webkit_user_content_manager_register_script_message_handler() on the shared
> WebKitUserContentManager instance, second and subsequent invocations with
> the same message name fail (i.e. the call return false) 

OK, stop here. You can only register a message name once, so it's expect that subsequent registrations with the same message name will fail. What would registering the same message a second time be expected to do? Registering once causes the script-message-received handler to be fired when the corresponding message is sent. Registering twice would cause ??? to happen? What are you expecting?

Remember the message is associated with the user content manager, not with any particular view, so it's not in any way view-specific.

> and no messages with
> that name are received from the ::script-message-received handler.

Hm, you should still receive messages due to the first successful registration, though...?

> I need to
> register it multiple times, once for each WebKitWebView instance because the
> messages are sent that are view-specific.

The normal solution for this is to include the page_id as part of the message and decide which view the message is for based on that. This should be safe indefinitely because all your views share the same security origin, so you won't have to deal with page_id changes during process swaps even if PSON gets enabled in the future. If the message can be sent from C, then an even better way would be to use the new messaging APIs added in 2.28, e.g. webkit_web_page_send_message_to_view(); then you won't have to manually pick the right web view: https://webkitgtk.org/reference/webkit2gtk/unstable/api-index-2-28.html

-- 
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/20191207/363f320f/attachment.htm>