[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

Carlos Garcia Campos <cgarcia at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cgarcia at igalia.com

--- Comment #5 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to Michael Gratton from comment #3)
> (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.

What failed exactly?

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

It shouldn't be that much work, I think.

> > (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/20191213/8ea1c8ac/attachment-0001.htm>