Bug 24905 – Value of navigator.mimeTypes is not always consistent with plug-in that will be used to load that MIME type

• Status: RESOLVED
• Resolution: WONTFIX
• Component: Plug-ins

[Simone Manganelli]

I've been trying to track down a bug with the ClickToFlash WebKit plugin, and it seems to point to a WebKit problem.

When ClickToFlash is installed in the global /Library/Internet Plug-Ins/ folder, the CNN video site ( http://cnn.com/video/ ) seems to work perfectly with ClickToFlash's default settings (note, these are the default settings of the latest source code which can be retrieved from github here: http://github.com/rentzsch/clicktoflash/tree/master ).

However, when the ClickToFlash plug-in is installed in ~/Library/Interent Plug-Ins/ — that is, inside the user's home folder instead of the global Internet Plug-Ins folder — the CNN video site does not work with ClickToFlash installed.

I've dug a bit into the source of the CNN video site and it seems that it is doing some detection on which plugins are installed.  The actual error that CNN's JavaScript code generates is the following:

PlugInDisabledError: Error Type: PlugInDisabledError
Occured While: Validating native player plugin.
Error Text: The Flash PlugIn/ActiveX Player is disabled or not associated with the "application/x-shockwave-flash" MIME type. FATAL ERROR CODE: 2000: Plugin Not Found (fatal error)

Both ClickToFlash and the Flash plugin register for the "application/x-shockwave-flash" MIME type, but ClickToFlash takes precedence over the stock Flash plugin and loads Flash content into its views.  However, due to this possible WebKit bug, WebKit reports different MIME type associations for the Flash plugin when you simply move it to the location inside the user's home folder, and therefore causes the CNN video website to only work when the plug-in is installed in the global plug-ins folder.

Any insight into why this might be happening and whether it really is a WebKit bug or not?

(This specific ClickToFlash bug can be tracked here: http://rentzsch.lighthouseapp.com/projects/24342/tickets/5-cnncom-videos-aint-workin )

[Simone Manganelli]

Just to clarify, the third-to-last paragraph should read like this:

Both ClickToFlash and the Flash plugin register for the "application/x-shockwave-flash" MIME type, but ClickToFlash takes precedence over the stock Flash plugin __since it's a WebKit plugin__ and loads Flash content into its views.  However, due to this possible WebKit bug, WebKit __seems to report__ different MIME type associations for the Flash plugin when you simply move __the ClickToFlash plugin__ to the location inside the user's home folder, and therefore causes the CNN video website to only work when the __ClickToFlash__ plug-in is installed in the global plug-ins folder.

[Simone Manganelli]

Created attachment 29902 [details]
clicktoflash plugin reduction

This code for the ClickToFlash plugin contains only the code needed to demonstrate the problem.

[Simone Manganelli]

FWIW, here is a better page that exhibits the problem: http://www.cnn.com/video/savp/evp/?loc=onsite&cnnSectionName=Politics&cnnSubSectionName=Political%20Ticker&vid=/video/politics/2009/04/29/sot.obama.100.specter.cnn .  I'm trying to reduce the page further, but having trouble due to all the massive JavaScript that is used to power even this small page.

I've also added an attachment that contains code for the ClickToFlash plugin that is just enough to demonstrate the problem.

Any word on action on this bug?

[Simone Manganelli]

Updated Steps to Reproduce with a partially reduced page:

1.  Download the attachment "clicktoflash_plugin_reduction" from this bug report.

2.  Open the zip file attachment, build the project, and install the plugin in /Library/Internet Plug-Ins/ .

3.  Open WebKit.  Navigate to http://homepage.mac.com/simx/cnnvideo3.html .  Note that in a few seconds, the Obama video loads and plays.

4.  Quit WebKit.

5.  Move the reduced ClickToFlash plugin from /Library/Internet Plug-Ins/ to ~/Library/Interent Plug-Ins/.

6.  Open WebKit again.  Navigate to http://homepage.mac.com/simx/cnnvideo3.html again.  Note that this time, the Obama video never loads and doesn't play.  Note that the only difference between step 3 and step 6 is the location of the WebKit plugin on the hard drive.

[Simone Manganelli]

Further reduction: http://homepage.mac.com/simx/cnnvideo4.html

[Mark Rowe (bdash)]

I found that in order to reproduce this bug I had to move the Flash plug-in in to ~/Library/Internet Plug-ins as well.

What's happening here is that CNN checks for Flash by doing navigator.mimeTypes['application/x-shockwave-flash'].enabledPlugin.name.indexOf('Shockwave Flash') != -1.  In cases where it fails navigator.mimeTypes['application/x-shockwave-flash'].enabledPlugin is returning the ClickToFlash plug-in info object that has a name of ClickToFlash.  When it passes, it's the plug-in info object for the real Flash plug-in.

The return value of navigator.mimeTypes appears to be determined by iterating through navigator.plugins and returning the first object that has the given MIME type.  The order of navigator.plugins on Mac OS X is retrieved from -[WebPluginDatabase plugins], where it returns the result of -allValues on an NSMutableDictionary object.   This means that the order of navigator.plugins is dependent on the hash algorithm used by NSDictionary when hashing the NSString of the path to the plug-in, which is used as the key to the dictionary.

It seems to me that we should be making an effort to return the plug-in from navigator.mimeTypes that will be used to handle the given MIME type.  On the Mac, this would mean having it respect the WebKit vs Netscape plug-in preference that we employ when instantiating plug-ins, as well as the version checking logic.  Doing so would cause CNN video to consistently fail when ClickToFlash was in use, so I think they'll need to fix their plug-in either way.

[Mark Rowe (bdash)]

<rdar://problem/6852016>

[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.