Bug 140392

One note: this patch sets the default insecure content policy to WEBKIT_INSECURE_CONTENT_POLICY_ALLOW_SOME. This is the setting most apps want to use, but it means that WebKitWebView:insecure-content-event could be emitted with WEBKIT_INSECURE_CONTENT_BLOCKED, which existing apps might not handle correctly (e.g. if they assert if the enum value is unrecognized, or check if it's one of the original two values and assume it's the other if not). Therefore we should consider either defaulting to WEBKIT_INSECURE_CONTENT_POLICY_ALLOW_ALL instead (in which case the new value would never be emitted), or addding a new signal WebKitWebView:insecure-content-blocked.

Created attachment 244520 [details] Patch

Generating webkit2gtk documentation... /home/slave/WebKit/Source/WebKit2/UIProcess/API/gtk/WebKitWebContext.h:121: warning: Value descriptions for WebKitInsecureContentPolicy are missing in source code comment block. /home/slave/WebKit/Source/WebKit2/UIProcess/API/gtk/WebKitWebView.h:150: warning: Value described in source code comment block but does not exist. ENUM: WebKitInsecureContentEvent Value: WEBKIT_INSECURE_CONTENT_BLOCKED. /home/slave/WebKit/Source/WebKit2/UIProcess/API/gtk/WebKitWebView.h:150: warning: Value description for WebKitInsecureContentEvent::WEBKIT_INSECURE_CONTENT_BLOCKED is missing in source code comment block. ^ I guess I need to talk to the gtkdoc people, as I can't figure out why it doesn't see the documentation.

Actually I have a guess: the bots need clean builds after r178103 to get rid of their tmpl directories.

Comment on attachment 244520 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=244520&action=review I think this patch could be split in two, one with the cross-platform changes including layout tests (and maybe even API tests as well) and then the GTK+ API one. That will make it easier for WebKit2 owners to review the cross-platform code, and for GTK+ reviewers the GTK+ part. I haven't looked at it in detail, so I have just a few general comments/questions. > Source/WebKit2/UIProcess/API/gtk/WebKitWebContext.cpp:944 > + * Since: 2.8 All Since tags should be 2.10 now. > Source/WebKit2/UIProcess/API/gtk/WebKitWebContext.cpp:956 > + for (WebKitWebView* webView : context->priv->webViews.values()) > + webkitWebViewSetPageInsecureContentPolicy(webView, policy); If this is actually a per page thing why not adding the API to the WebView? or even as a setting, so that you can share the policy with multiple web views. > Source/WebKit2/UIProcess/API/gtk/WebKitWebContext.h:112 > + * @WEBKIT_INSECURE_CONTENT_POLICY_ALLOW_SOME: Block some mixed content. Some > + * mixed content will be permitted to preserve compatibility with web sites. > + * For example, insecure images, audio, video, and forms are currently > + * permitted. The set of permitted insecure content is subject to change. Is this still true? or are only images allowed. We should probably say here that insecure-content-detected will be called for the allowed as a mode of warning. > Source/WebKit2/UIProcess/API/gtk/WebKitWebView.cpp:2496 > +void webkit_web_view_reload_with_insecure_content(WebKitWebView* webView) > +{ > + g_return_if_fail(WEBKIT_IS_WEB_VIEW(webView)); > + > + webkitWebViewSetPageInsecureContentPolicy(webView, WEBKIT_INSECURE_CONTENT_POLICY_ALLOW_ALL); > + webkit_web_view_reload(webView); I'm not sure about this, I think it would be easier if the app does this. Change the setting/policy, and the reload. > Source/WebKit2/UIProcess/WebPageProxy.cpp:5363 > +void WebPageProxy::allowDisplayOfInsecureContent(bool allowed) > +{ > + if (!isValid()) > + return; > + > + process().send(Messages::WebPage::AllowDisplayOfInsecureContent(allowed), m_pageID); > +} > + > +void WebPageProxy::allowRunningOfInsecureContent(bool allowed) > +{ > + if (!isValid()) > + return; > + > + process().send(Messages::WebPage::AllowRunningOfInsecureContent(allowed), m_pageID); I think it would be quite common to call both methods. Maybe we could use a single message allowInsecureContent with flags as parameter. > Source/WebKit2/WebProcess/WebPage/WebPage.cpp:2664 > +void WebPage::allowDisplayOfInsecureContent(bool allowed) > +{ > + m_page->settings().setAllowDisplayOfInsecureContent(allowed); > +} > + > +void WebPage::allowRunningOfInsecureContent(bool allowed) > +{ > + m_page->settings().setAllowRunningOfInsecureContent(allowed); > +} Since they are indeed settings, why not exposing them as settings? I think everythihng will be easier.

(In reply to comment #5) > I think this patch could be split in two, one with the cross-platform > changes including layout tests (and maybe even API tests as well) and then > the GTK+ API one. The cross-platform changes here are (a) new load event didBlockInsecureContent and (b) control of the existing WebCore insecure content settings from WK2. Neither of that can be tested with layout tests; they need API tests. (Using a setting from a layout test requires a completely different code path.) I don't want to write cross-platform API tests since they would not be easy to write (HTTP server required: I want libsoup for that!). But see bug #140940 for related layout tests. > If this is actually a per page thing why not adding the API to the WebView? > or even as a setting, so that you can share the policy with multiple web > views. I think allowing this setting to be changed for each webview would be unnecessary complexity in the API. We only need to expose one global policy that affects all web views. The only reason to expose it as a per-webview setting would be if the application could change the setting for the web view after the load is committed but before loading begins: that way we don't have API to allow changing insecure content settings per host. But I'm not sure if that's how WebKit works or not: when the load-event signal is fired in the UI process, is the web process waiting patiently for the browser to handle that signal before it starts loading, or is it already loading things? If it's already loading things then I don't think the browser would have any use for a per-webview setting. But if it's waiting patiently, then that would be a great idea. I can't remember for sure what my reason for not using normal settings was. I think it was because I was brand new when I wrote most of this and didn't know what I was doing, but maybe I had a good reason I forgot. Probably it was that I did not want an important security feature to be hidden as a setting, and at the time I was thinking that we would not want to change the default behavior since it would be an incompatible change. Anyway I will try removing the API from WebKitWebContent and changing it to use settings and then see what breaks. > Is this still true? or are only images allowed. We should probably say here > that insecure-content-detected will be called for the allowed as a mode of > warning. I think it's still true. At least, it needs to be still true. :) I think we would break too many sites if we block videos or forms. My tests in bug #140940 will catch a change regarding videos. I'm not sure what we do for forms, that's bug #142342. > I'm not sure about this, I think it would be easier if the app does this. > Change the setting/policy, and the reload. Eh... I'm not sure about this API either. What we really want is a way to whitelist specific hosts. > I think it would be quite common to call both methods. Maybe we could use a > single message allowInsecureContent with flags as parameter. Let's wait for bug #142469 (yes another bug!) before deciding how to handle this. Those settings have poor names, and I need to be on the same page as Apple on what the semantics of them should be.

(In reply to comment #6) > (In reply to comment #5) > > I think this patch could be split in two, one with the cross-platform > > changes including layout tests (and maybe even API tests as well) and then > > the GTK+ API one. > > The cross-platform changes here are (a) new load event > didBlockInsecureContent and (b) control of the existing WebCore insecure > content settings from WK2. Neither of that can be tested with layout tests; why not? > they need API tests. (Using a setting from a layout test requires a > completely different code path.) I don't want to write cross-platform API > tests since they would not be easy to write (HTTP server required: I want > libsoup for that!). Right, that's why I said *maybe* an API test. > But see bug #140940 for related layout tests. So, they are layout tests for this then, I'm confused.

> why not? Well to test the didBlockInsecureContent event we would need to hook into that event somehow: that requires an API test. Same for exposing the didRunInsecureContent and didDisplayInsecureContent events, which already existed in WebCore but are new to WK2. And we can't test WK2 things with layout tests anyway, since they need to work for WK1. > So, they are layout tests for this then, I'm confused. They are "related" layout tests, to make sure blocking insecure content works properly, but they don't actually test any of the functionality added in this patch. WebCore already supports mixed content blocking as did WK1. It's only new functionality for WK2.

(In reply to comment #6) > I can't remember for sure what my reason for not using normal settings was. > I think it was because I was brand new when I wrote most of this and didn't > know what I was doing, but maybe I had a good reason I forgot. Well I guess I still did not know what I was doing, because up until today I assumed WebKitSettings were applied to the WebKitWebContext, not the WebKitWebView. As they're per-view settings I think we can use WebKitSettings just fine. That simplifies things considerably.

This API might have been a good idea five years ago, but it no longer makes sense in 2015.