Bug 161615
| Summary: | [GTK] User script message handlers broken in related web views | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Michael Catanzaro <mcatanzaro> |
| Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | Normal | CC: | aperez, bugs-noreply, mcatanzaro |
| Priority: | P2 | ||
| Version: | Other | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| See Also: | https://bugzilla.gnome.org/show_bug.cgi?id=769627 | ||
Michael Catanzaro
webkit_web_view_new_with_related_view() creates a new WebKitWebView with the same WebKitUserContentManager as the related view. It works in the UI process, but in the web process the new WebKit::WebPage object gets created with a different WebKit::WebUserContentController object. Hence, script message handlers never get executed in related views.
Sad!
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Michael Catanzaro
OK, so our API works fine: the problem only occurs when the related view is created via JavaScript on a web site. In that case, priv->userContentManager is unset when webkitWebViewConstructed() calls webkitWebContextCreatePageForWebView(), because there's no code to set it anywhere.
Michael Catanzaro
(In reply to comment #1)
> OK, so our API works fine: the problem only occurs when the related view is
> created via JavaScript on a web site.
This is incorrect, please disregard.
Michael Catanzaro
(In reply to comment #0)
> webkit_web_view_new_with_related_view() creates a new WebKitWebView with the
> same WebKitUserContentManager as the related view. It works in the UI
> process
This is wrong too. The failure is in the UI process. webkit_web_view_new_with_related_view() results in a WebKitWebView with a null WebKitUserContentManager. It gets set properly in webkitWebViewSetProperty, but somehow gets nulled out before webkitWebViewConstructed is called.
Michael Catanzaro
(In reply to comment #3)
> It gets set properly in webkitWebViewSetProperty, but somehow gets nulled out before webkitWebViewConstructed is called.
Even this is wrong. It doesn't get set properly; I accidentally printed a smart pointer location when debugging, instead of the actual null pointer.
Michael Catanzaro
It's an Epiphany bug.
Michael Catanzaro
(In reply to comment #5)
> It's an Epiphany bug.
Sorry for being terrible at Bugzilla and making six comments in a row.
Anyway, the problem is we have this ephy_web_view_new_with_related_view function, which I misread as webkit_web_view_new_with_related_view. The WebKit API function is just fine. The Epiphany function uses g_object_new directly, assuming that setting the related-view property guarantees that the user content manager and settings will be set appropriately. That's not right, since they're only set by the webkit_web_view_new_with_related_view convenience func.