Bug 127415 – PDFPlugin: Use PDFPlugin even if there's an external plugin installed, if it's blocked

• Status: RESOLVED
• Resolution: FIXED
• Component: PDF

[Tim Horton]

If there is an external PDF plugin but it's blocked, we should still load in PDFPlugin, with a context menu option to perform the equivalent of the unavailable plugin button (thus allowing the client to unblock the plugin).

<rdar://problem/12482452>

[Tim Horton]

Created attachment 221837 [details]
patch

I hate adding more things to findPlugin and pluginLoadPolicy but it is the most straightforward way to go.

[Tim Horton]

Created attachment 221839 [details]
rebase

[Sam Weinig]

Comment on attachment 221839 [details]
rebase

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

> Source/WebKit2/UIProcess/API/C/WKPageLoaderClient.h:396
> +    // Version 4.
> +    WKPageWebGLLoadPolicyCallback                                       webGLLoadPolicy;
> +
> +    // Version 5.
> +    WKPagePluginLoadPolicyCallback                                      pluginLoadPolicy;

I'm not clear if we need to rev for this.

[Tim Horton]

(In reply to comment #3)
> (From update of attachment 221839 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=221839&action=review
> 
> > Source/WebKit2/UIProcess/API/C/WKPageLoaderClient.h:396
> > +    // Version 4.
> > +    WKPageWebGLLoadPolicyCallback                                       webGLLoadPolicy;
> > +
> > +    // Version 5.
> > +    WKPagePluginLoadPolicyCallback                                      pluginLoadPolicy;
> 
> I'm not clear if we need to rev for this.

Looks like you’re right.

[Tim Horton]

http://trac.webkit.org/changeset/162629

[Tim Horton]

Part of this was reverted in https://trac.webkit.org/r162883