Bug 43797 – Navigating to a plug-in document fails if plug-ins are disabled

• Component: Plug-ins
• Status: RESOLVED WONTFIX

[Bernhard Bauer]

Steps to reproduce: 
* Disable plug-ins
* Go to a URL that's displayed by a plug-in (e.g. a PDF or SWF file)

In Safari, you get the rather unhelpful error message 'Safari can’t open <URL> because Mac OS X doesn’t recognize Internet addresses starting with “http:”.', Chrome just silently fails (or crashes if the navigation happens to open a new tab, but that's another bug).

The navigation fails because Page::pluginData returns 0 if plug-ins are disabled, so the checks to see if a plug-in can handle the document fail. I think we should simply return the pluginData object here. There are additional checks later on to make sure the plug-in is not actually loaded, and I added checks in DOMPluginArray and DOMMimeTypeArray to return empty lists there.

For Chrome, the result is that you get an empty page and the plug-in blocked indicator, which is more helpful than silently failing. I couldn't check the result for Safari.

This is also a bit more consistent with the behavior in SubFrameLoader::shouldUsePlugin, which returns true if plug-ins are disabled, so that we try to load the plug-in and fail, notifying the FrameLoaderClient about it.

[Bernhard Bauer]

Created attachment 64024 [details]
Return plugin data if plugins are disabled.

[Eric Seidel (no email)]

Comment on attachment 64024 [details]
Return plugin data if plugins are disabled.

This needs a layout test, or explanation (in the ChangeLog) of why such a test is impossible.

[Alexey Proskuryakov]

Mass closing plug-in bugs, as plug-in support has been removed from WebKit.

Please comment and/or reopen if this still affects WebKit in some way.