[webkit-gtk] Block/Unblock plugin API
Marcos Chavarría Teijeiro
chavarria1991 at gmail.com
Thu Mar 19 02:52:44 PDT 2015
I have been implementing this feature during the last month. The
aproximation I took was to use a separate type for each signal. So the
-> WebKitPluginLoadPolicy (* load_plugin) (WebKitWebView *web_view,
-> void (* plugin_blocked) (WebKitWebView *web_view,
-> void (* unavailable_plugin_activated) (WebKitWebView *web_view,
The resulting path with the tests can be found here (
In the meanwhile the following patch has been landed "Allow clients to
selectively disable plug-ins" (
https://bugs.webkit.org/show_bug.cgi?id=142506). This patch implements a
way to set the load policy for each plugin and host. The defined policies
are the following:
* PluginLoadClientPolicyUndefined -> No client-specific plug-in load policy
has been defined. The plug-in should be visible in navigator.plugins and
WebKit should synchronously ask the client whether the plug-in should be
* PluginLoadClientPolicyBlock -> The plug-in module should be blocked from
being instantiated. The plug-in should be hidden in navigator.plugins.
* PluginLoadClientPolicyAsk -> WebKit should synchronously ask the client
whether the plug-in should be loaded. The plug-in should be visible in
* PluginLoadClientPolicyAllow -> The plug-in module may be loaded if WebKit
is not blocking it.
* PluginLoadClientPolicyAllowAlways -> The plug-in module should be loaded
irrespective of whether WebKit has asked it to be blocked.
It implements the methods setPluginLoadClientPolicy and
clearPluginClientPolicies on WebProcessPool to be able to set the plugin
load client policy and to clear all existent policies.
So, we should modify our block/unblock API to support this new client
In my opinion the only signal that should modify its behaviour is
load-plugin. This signal only needs to be called if the ClientPolicies are
Undefined or Ask. In other cases we should return Block or Allow without
asking to the client application. The other signal maintain their behaviour.
On the other hand we should add some API to allow the client to set this
policies for each plugin and host. We could add three methods to Plugin
(WebKitPlugin* plugin, const gchar* host);
This method allows the client to get the current policy for the given host.
(WebKitPlugin* plugin, const gchar* host,
This method allows the client to set the current policy for the given host.
webkit_plugin_get_client_policy_hosts (WebKitPlugin* plugin);
This method allows the client to get a list of host which have a custom
The WebKitPluginLoadClientPolicy enum contains the following values:
In addition we could add a method to the WebContext class for been able to
clear all plugin policies:
webkit_web_context_clear_plugin_client_policies (WebKitWebContext* context);
This method allows the client to clears all custom policies.
I see a few problems with the proposed new API:
* The only methods exposed in the WebProcessPool are
setPluginLoadClientPolicy and clearPluginClientPolicies this methods could
be used to implement webkit_plugin_set_client_policy and
webkit_context_clear_plugin_client_policies but the remaining two API
methods need that we implement some methods in the WebProcessPool class
which should not be difficult but this patch has not implement this methods
in spite of the fact that it do implement
WebPlatformStrategies::pluginLoadClientPolicyForHost. This method does what
we need for webkit_plugin_get_Client_policy_hosts but its not exposed in
the C API. There could be some side effects that I dont see.
* I really don't like the name for webkit_plugin_get_client_policy_hosts.
2015-01-08 18:20 GMT+01:00 Gustavo Noronha Silva <gns at gnome.org>:
> On Tue, 2014-12-16 at 13:47 +0100, Carlos Garcia Campos wrote:
> > I think this API provides all the flexibility that the internal or C API
> > allows. There are a few things I'm not completely sure about:
> I agree, it looks sound to me.
> > - WebKitPluginLoadRequest: do we really need the get_page_uri?
> > wouldn't that be always the current web view uri? I've added the method
> > because that information is provided by the loader client callback, but
> > we need to make sure it's actually needed. For a first version we could
> > avoid that method, and add it later if it's actually useful. But without
> > method, the request is a very simple object, so maybe we could pass the
> > WebKitPlugin directly to the signal and pass an out parameter for the
> > button description. That would make everything simpler, but we won't be
> > able to add more info to the signal without breaking the API.
> I would keep LoadRequest instead of passing the plugin directly, but I
> also see no reason to provide get_page_uri at this point.
> > - plugin-blocked: In this case I did the opposite, passing the
> > information as signal arguments. Currently wk passes the frame URL, page
> > URL, plugin mime type and whether the plugin is obscured. We might use a
> > boxed type here too, for example to also provide the page uri and the
> > plugin mime type if needed/useful.
> I think a separate type is better, for flexibility. I'd like to think we
> would not need to add anything, but we can't be sure, so…
> > - plugin-unavailability-button-clicked: the signal name and the boxed
> > type used to provide the information are too long, we could think about
> > better names. Again I'm not sure about the needed to provide the page
> > uri. Also internally, wk passes the plugin page attribute (I guess this
> > is the page where the plugin can be downloaded in case of missing
> > plugins).
> I wouldn't mention a button on the API, in any case.
> Gustavo Noronha Silva <gns at gnome.org>
> GNOME Project
> webkit-gtk mailing list
> webkit-gtk at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-gtk