<div dir="ltr"><div><div><div><div>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 result was:<br><br>-&gt;  WebKitPluginLoadPolicy (* load_plugin) (WebKitWebView *web_view, WebKitPluginLoadRequest *request);<br>-&gt;  void (* plugin_blocked) (WebKitWebView *web_view, WebKitPluginBlockedInformation *info);<br>-&gt;  void (* unavailable_plugin_activated) (WebKitWebView *web_view, WebKitPluginUnavailabilityInformation *info);<br><br></div><div>The resulting path with the tests can be found here (<a href="https://bugs.webkit.org/attachment.cgi?id=248058&amp;action=prettypatch">https://bugs.webkit.org/attachment.cgi?id=248058&amp;action=prettypatch</a>).<br></div><div><br>In the meanwhile the following patch has been landed  &quot;Allow clients to selectively disable plug-ins&quot; (<a href="https://bugs.webkit.org/show_bug.cgi?id=142506">https://bugs.webkit.org/show_bug.cgi?id=142506</a>). This patch implements a way to set the load policy for each plugin and host. The defined policies are the following:<br><br>* PluginLoadClientPolicyUndefined -&gt; 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 loaded.<br>* PluginLoadClientPolicyBlock -&gt; The plug-in module should be blocked from being instantiated. The plug-in should be hidden in navigator.plugins.<br>* PluginLoadClientPolicyAsk -&gt; WebKit should synchronously ask the client whether the plug-in should be loaded. The plug-in should be visible in navigator.plugins. <br>* PluginLoadClientPolicyAllow -&gt; The plug-in module may be loaded if WebKit is not blocking it.<br>* PluginLoadClientPolicyAllowAlways -&gt; The plug-in module should be loaded irrespective of whether WebKit has asked it to be blocked.<br><br></div><div>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.<br></div><div><br>So, we should modify our block/unblock API to support this new client policies.<br><br>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.<br><br>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 class:<br><br>WebKitPluginLoadClientPolicy webkit_plugin_get_client_policy                          (WebKitPlugin* plugin, const gchar* host);<br>This method allows the client to get the current policy for the given host.<br></div><div><br>void                                        webkit_plugin_set_client_policy                         (WebKitPlugin* plugin, const gchar* host, WebKitPluginLoadClientPolicy policy);<br>This method allows the client to set the current policy for the given host.<br><br>GList                                      webkit_plugin_get_client_policy_hosts               (WebKitPlugin* plugin);<br></div><div>This method allows the client to get a list of host which have a custom policy.<br></div><div><br></div>The WebKitPluginLoadClientPolicy enum contains the following values:<br></div>WEBKIT_PLUGIN_CLIENT_LOAD_POLICY_UNDEFINED<br>WEBKIT_PLUGIN_CLIENT_LOAD_POLICY_BLOCK<br></div></div>WEBKIT_PLUGIN_CLIENT_LOAD_POLICY_ASK<br>WEBKIT_PLUGIN_CLIENT_LOAD_POLICY_ALLOW<br><div><div><div><div>WEBKIT_PLUGIN_CLIENT_LOAD_POLICY_ALLOW_ALWAYS<br></div><div><br>In addition we could add a method to the WebContext class for been able to clear all plugin policies:<br>void                                       webkit_web_context_clear_plugin_client_policies (WebKitWebContext* context);<br></div><div>This method allows the client to clears all custom policies.<br></div><div><br></div><div>I see a few problems with the proposed new API:<br><br></div><div>* 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.<br><br></div><div>* I really don&#39;t like the name for webkit_plugin_get_client_policy_hosts. <br></div><div> <br>2015-01-08 18:20 GMT+01:00 Gustavo Noronha Silva &lt;<a href="mailto:gns@gnome.org">gns@gnome.org</a>&gt;:<br>&gt;<br>&gt; On Tue, 2014-12-16 at 13:47 +0100, Carlos Garcia Campos wrote:<br>&gt; &gt; I think this API provides all the flexibility that the internal or C API<br>&gt; &gt; allows. There are a few things I&#39;m not completely sure about:<br>&gt;<br>&gt; I agree, it looks sound to me.<br>&gt;<br>&gt; &gt;   - WebKitPluginLoadRequest: do we really need the get_page_uri?<br>&gt; &gt; wouldn&#39;t that be always the current web view uri? I&#39;ve added the method<br>&gt; &gt; because that information is provided by the loader client callback, but<br>&gt; &gt; we need to make sure it&#39;s actually needed. For a first version we could<br>&gt; &gt; avoid that method, and add it later if it&#39;s actually useful. But without<br>&gt; &gt; method, the request is a very simple object, so maybe we could pass the<br>&gt; &gt; WebKitPlugin directly to the signal and pass an out parameter for the<br>&gt; &gt; button description. That would make everything simpler, but we won&#39;t be<br>&gt; &gt; able to add more info to the signal without breaking the API.<br>&gt;<br>&gt; I would keep LoadRequest instead of passing the plugin directly, but I<br>&gt; also see no reason to provide get_page_uri at this point.<br>&gt;<br>&gt; &gt;   - plugin-blocked: In this case I did the opposite, passing the<br>&gt; &gt; information as signal arguments. Currently wk passes the frame URL, page<br>&gt; &gt; URL, plugin mime type and whether the plugin is obscured. We might use a<br>&gt; &gt; boxed type here too, for example to also provide the page uri and the<br>&gt; &gt; plugin mime type if needed/useful.<br>&gt;<br>&gt; I think a separate type is better, for flexibility. I&#39;d like to think we<br>&gt; would not need to add anything, but we can&#39;t be sure, so…<br>&gt;<br>&gt; &gt;   - plugin-unavailability-button-clicked: the signal name and the boxed<br>&gt; &gt; type used to provide the information are too long, we could think about<br>&gt; &gt; better names. Again I&#39;m not sure about the needed to provide the page<br>&gt; &gt; uri. Also internally, wk passes the plugin page attribute (I guess this<br>&gt; &gt; is the page where the plugin can be downloaded in case of missing<br>&gt; &gt; plugins).<br>&gt;<br>&gt; unavailable-plugin-activated?<br>&gt;<br>&gt; I wouldn&#39;t mention a button on the API, in any case.<br>&gt;<br>&gt; Cheers,<br>&gt; --<br>&gt; Gustavo Noronha Silva &lt;<a href="mailto:gns@gnome.org">gns@gnome.org</a>&gt;<br>&gt; GNOME Project<br>&gt;<br>&gt; _______________________________________________<br>&gt; webkit-gtk mailing list<br>&gt; <a href="mailto:webkit-gtk@lists.webkit.org">webkit-gtk@lists.webkit.org</a><br>&gt; <a href="https://lists.webkit.org/mailman/listinfo/webkit-gtk">https://lists.webkit.org/mailman/listinfo/webkit-gtk</a><br><br></div></div></div></div></div>