[Webkit-unassigned] [Bug 134357] [GTK][WebKit2] Missing API to disable WebKitPlugin

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=134357

Carlos Garcia Campos <cgarcia at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #243189|review?                     |review-
              Flags|                            |

--- Comment #9 from Carlos Garcia Campos <cgarcia at igalia.com> ---
Comment on attachment 243189
  --> https://bugs.webkit.org/attachment.cgi?id=243189
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=243189&action=review

After thinking about this again, I think we could expose this in a different way, giving more control to the application. We could expose the pluginLoadPolicy callback as a signal of WebKitWebView, where the user can connect to decide what to do about the plugin. And we should also expose the unavailablePluginButtonClicked so that the application can ask the user whether to enable the particular plugin or not and reload the page. This way, it's the application the one keeping the list of blocking plugins, and we keep the WebKitPlugin object as read-only.

> Source/WebKit2/Shared/Plugins/PluginModuleInfo.h:62
> +    bool isBlocked;

I don't think we need to keep this here. This is for the information that the plugin provides, not for the plugin state.

> Source/WebKit2/UIProcess/API/gtk/WebKitLoaderClient.cpp:123
> +    bool blocked = toImpl(pluginInfoDictionary)->get<API::Boolean>(pluginInformationIsBlockedKey())->value();
> +    return blocked ? PluginModuleBlocked : PluginModuleLoadNormally;

We should provide the unavailabilityDescription, I guess. I think we should keep the list of plugins blocked in GTK specific code, and check here if the given plugin is blocked or not.

> Source/WebKit2/UIProcess/API/gtk/WebKitLoaderClient.cpp:168
>          0, // didLayout
>          0, // pluginLoadPolicy_deprecatedForUseWithV2
>          0, // pluginDidFail
> -        0, // pluginLoadPolicy
> +        pluginLoadPolicy // pluginLoadPolicy

What happens when a plugin is blocked and the user clicks on the unavailable button? I think we should also implement unavailablePluginButtonClicked in the UI client.

> Source/WebKit2/UIProcess/Plugins/PluginInfoStore.cpp:71
> +#if PLATFORM(GTK)
> +        if (PluginInfoStore::m_loadedPluginListIsUpToDate)
> +#endif

I don't understand why this is needed. The pluginLoadPolicy will be called every time the page is reloaded and there are plugins.

> Source/WebKit2/UIProcess/Plugins/PluginInfoStore.cpp:96
> +#if PLATFORM(GTK)
> +    PluginInfoStore::m_loadedPluginListIsUpToDate = true;
> +#endif

Ditto.

> Source/WebKit2/UIProcess/Plugins/PluginInfoStore.h:65
> +#if PLATFORM(GTK)
> +    static void setBlockedPlugin(PluginModuleInfo&, bool);
> +#endif

This could be handled in the GTK+ specific code.

> Source/WebKit2/UIProcess/Plugins/PluginInfoStore.h:110
> +#if PLATFORM(GTK)
> +    static Vector<String> m_blockedPluginsPaths;
> +    static bool m_loadedPluginListIsUpToDate;
> +#endif

Ditto.

> Source/WebKit2/UIProcess/Plugins/unix/PluginInfoStoreUnix.cpp:107
> +    for (const auto& blocked_plugin_path : m_blockedPluginsPaths) {

blocked_plugin_path -> blockedPluginPath

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20141212/e42c9620/attachment-0002.html>