[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 #3 from Michael Gratton <mike at vee.net> ---
(In reply to Michael Catanzaro from comment #2)
> (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?

Yeah, good point. I still had the old model in my head where under the WEBKIT_PROCESS_MODEL_SHARED_SECONDARY_PROCESS model you could still have a WebKitUserContentManager per web view.

I just tried using a per-view WebKitUserContentManager with a custom ctor instead  of calling webkit_web_view_new_with_related_view() directly, one that set the `related-view` property and also `user-content-manager` with a new WebKitUserContentManager instance, but that didn't seem to work.

Supporting this would make porting away from using WEBKIT_PROCESS_MODEL_SHARED_SECONDARY_PROCESS much easier.

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

Yep, the first registered handler works as would be expected.

> 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.

Okay, any clues about how to access `page_id` from JS scripts in the page? There's nothing about it in the docs.

I'll look into porting to the new Message API in the future, but that's potentially a lot of work, so probably not this cycle.

> (In reply to Michael Gratton from comment #0)
>> Nothing is logged when WEBKIT_DEBUG=all
> 
> 
> That's not a thing :)

It is according to https://trac.webkit.org/wiki/WebKitGTK/Debugging /:)

-- 
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/b790dba8/attachment-0001.htm>