Speaking of everybody’s favorite WebKit plug-in, here’s how it works. This should help you understand how it fails on some sites, and maybe aid you in contributing to its development.
First off, it is a WebKit plug-in; it’s written in Cocoa and uses WebKit’s own plug-in API. It does not use the Netscape plug-in API.
A WebKit plug-in declares a list of MIME media types in its Info.plist bundle. It does this by way of a dictionary of dictionaries:
<key>WebPluginMIMETypes</key> <dict> <key>application/x-shockwave-flash</key> <dict> <key>WebPluginTypeDescription</key> <string>ClickToFlash</string> </dict> </dict>
WebKit only loads a WebKit plug-in when it first encounters some content that it needs the plug-in for. It uses these Info.plist dictionaries to know which plug-in it needs to load. So, in the case of ClickToFlash, it only loads ClickToFlash when it encounters something that is of type
You will notice that ClickToFlash only declares one of these.
As it turns out, everybody only uses
application/x-shockwave-flash. ClickToFlash exploits this.
When you click on the ClickToFlash view, it modifies the
embed element that the view represents, changing its
type attribute to the other type—the one ClickToFlash doesn’t declare; the one no webpages actually use. WebKit notices this change and looks again for a plug-in to handle the movie. This time, it comes up with only one handler: the real Flash Player plug-in.
So now that you know how ClickToFlash works, maybe you can help fix its bugs?
* Flash Player doesn’t declare its MIME types in its Info.plist; it declares them in a resource file, in ‘STR#’ resource 128. Thanks to WebKit developer Mark Rowe for reminding me to look for a resource. ↶