User content manager is a construct only property, so if not set by the user the web view doesn't have any. We can create a default one, like we do for settings, when user didn't provide one.
Created attachment 303315 [details] Patch I need this for the new remote inspector, that uses a custom protocol page with user script messages.
Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See http://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API
Comment on attachment 303315 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=303315&action=review > Source/WebKit2/UIProcess/API/gtk/WebKitWebView.cpp:2267 > * Returns: (transfer none): the #WebKitUserContentManager associated with the view So it's no longer (transfer none), then. Technically an introspection API break, but breakage should be minimal....
(In reply to comment #3) > Comment on attachment 303315 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=303315&action=review > > > Source/WebKit2/UIProcess/API/gtk/WebKitWebView.cpp:2267 > > * Returns: (transfer none): the #WebKitUserContentManager associated with the view > > So it's no longer (transfer none), then. Technically an introspection API > break, but breakage should be minimal.... Why not? the default user content manager is also owned by the web view, so this is still transfer none.
(In reply to comment #4) > Why not? the default user content manager is also owned by the web view, so > this is still transfer none. Ah, dumb, sorry. I confused (transfer none) with (allow none).
Comment on attachment 303315 [details] Patch Clearing flags on attachment: 303315 Committed r213366: <http://trac.webkit.org/changeset/213366>
All reviewed patches have been landed. Closing bug.