[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 #4 from Michael Catanzaro <mcatanzaro at gnome.org> ---
(In reply to Michael Gratton from comment #3)
> 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.

Well you absolutely still can, if that's what you want to do. But it sounds like you are using the same user content manager for both views. It's up to you whether you want to use one user content manager for all views (this is what Epiphany used to do until very recently) or one per view (this is what Epiphany does currently).

> 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... it *should* work. Maybe we have a bug here?

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

You can't get the page_id from JavaScript. You have to pass it to the JS from C. Look at ephy-web-process-extension.c for example.

> > (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 /:)

Oh, I didn't know. Note the wiki page says it only works in debug builds.

-- 
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/0da56463/attachment.htm>