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.
Created attachment 64024 [details] Return plugin data if plugins are disabled.
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.
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.