GNOME Bugzilla – Bug 769627
Script message handlers broken for related web views
Last modified: 2016-09-06 05:45:52 UTC
This is broken in both master and 3.20.3. Somehow, we can get into a state where script message handlers don't work anymore, even though the web extension is otherwise functioning fine (i.e. has a working D-Bus connection with the UI process). Unfortunately my current reproducer requires two Google accounts; I need to to find a better one: * Visit https://mail.google.com/ while logged into a Google account * Click your avatar, then click Add Account * A new tab is created with a list of your other Google accounts * Click on an account to get a password form. Enter some invalid password to trigger the formAuthData message. Expected behavior: info bar appears asking user if password should be saved in the keyring Actual behavior: ** (WebKitWebProcess:28475): WARNING **: Error sending formAuthData message And the UI process never sees the message sent from the web process. Unfortunately our API does not include any way to get information about the error. It's not just the formAuthData message. If you then navigate to https://cacert.com in that web view, the Load Anyway button on the TLS error page doesn't do anything: the web extension never sees the tlsErrorPage message sent from the UI process. Both messages still work properly in all other browser tabs, just the one created from Google's JavaScript is broken. I haven't debugged it yet, so this is just a blind guess, but perhaps both tabs are using the same web process, and script messages are broken in that case.
(In reply to Michael Catanzaro from comment #0) > I haven't debugged it yet, so this is just a blind guess, but perhaps both > tabs are using the same web process, and script messages are broken in that > case. I think this is WebKit #152386; let's assume so until proven otherwise.
Reopening this as that WebKit bug is fixed.
The WebKit::WebPage is being created with a different WebKit::WebUserContentController, which is wrong. Filed a new WebKit bug #161615.
*** Bug 748691 has been marked as a duplicate of this bug. ***
The following fix has been pushed: f8e79e6 web-view: set user-content-manager when creating related view
Created attachment 334875 [details] [review] web-view: set user-content-manager when creating related view WebKit does not set the WebKitUserContentManager from the related view GObject property. The WebKitUserContentManager only gets set automatically when using the webkit_web_context_new_with_related_view GObject API. This means all our script message handlers (and also user CSS) were broken in related views (views that share the same web process), e.g. when using the Add Account feature to switch between multiple Google accounts on Google pages. This is probably also the cause of user complaints that sometimes bypassing the unacceptable TLS certificate error page doesn't work.