WebKit can not load Mozilla Plug-ins having uppercase in their mime type description string. For example a HelloWorld plug-in with mime type as "application/sample-helloworld" is loaded successfully but when the mime type string becomes "application/Sample-HelloWorld" it fails to load. Where as Mozilla Firefox browser loads it properly. With a little debugging I found that WebKit converts the mime type strings to lower case explicitly, before searching for the plug-ins in plug-in directories. Is there any special reason behind that? If not, I think, they should not be converted to lower case. The files and functions where they are converted to lower case are as below 1. In the file "WebCore/html/HTMLObjectElement.cpp", in the function "void HTMLObjectElement::parseMappedAttribute(MappedAttribute *attr)" the line "m_serviceType = val.lower();" 2. In the file "WebCore/plugins/PluginDatabase.cpp", in the function "PluginPackage* PluginDatabase::pluginForMIMEType(const String& mimeType)" the line "String key = mimeType.lower();" 3. In the file "WebCore/plugins/PluginDatabase.cpp", in the function "void PluginDatabase::setPreferredPluginForMIMEType(const String& mimeType, PluginPackage* plugin)" the line "m_preferredPlugins.set(mimeType.lower(), plugin);"
RFC 2045 says that matching of media types should be case insensitive. Whether it's correct to change attribute value case is a separate question. I don't think we have such problem on Mac, because WebBasePluginPackage lowercases MIME strings it gets from plug-ins.
The plug-in library, I have created, is for Scriptable plug-in objects. Though the case-insensitivity holds good, still WebKit does not load it, where as Firefox Mozilla loads it properly and invoke it for the the properties and methods of the Scriptable objects. Note: When I change the above statements, such as, not to convert the mime-type to lower case, it works fine.
WebKit converts all the characters in the Mime-Type string mentioned in the type="application/Sample-HelloWorld" attribute of the <object> tag to lower case as "application/sample-helloworld" and give it to the NPP_New() call. So, even though in the HTML page object tag has type="application/Sample-HelloWorld" and I return "application/sample-helloworld" as mime-type from my Plug-in then it loads fine. But in Firefox this scenario does not work. I could not find any where the reason of converting the attribute values to lower case explicitly. I don't think that this problem is only for [Qt] or [Gtk] ports. This problem will be there if upper-cases MIME strings are returned from plug-ins in [Mac] port also. Since RFC 2045 says that matching of media types should be case insensitive, So Plug-ins can have upper-case in their Mime-type strings.
Another solution to this problem is as below. --------------------------------------------- As said above the string comparison of mime-types should be case insensitve but I guess here in the below code it goes wrong. When pluginForMIMEType() is called from findPlugin(), the mime-type string is in lower cases. But the mimeToDescriptions() for PluginPackage have upper case characters as recieved from the plugin library. Since, mimeToDescriptions().contains(key) will do a case sensitive comparison so the PluginPackage will not be identified for that mime-type. Code Changes: ------------- 1. In the file "WebCore/plugins/PluginDatabase.cpp", in the function "PluginPackage* PluginDatabase::pluginForMIMEType(const String& mimeType)" the lines "if (plugin->mimeToDescriptions().contains(key)) pluginChoices.append(plugin);" can be replaced with "MIMEToDescriptionsMap::const_iterator map_it = (*it)->mimeToDescriptions().begin(); MIMEToDescriptionsMap::const_iterator map_end = (*it)->mimeToDescriptions().end(); for (; map_it != map_end; ++map_it){ if (equalIgnoringCase(map_it->first, key)){ pluginChoices.append(plugin); continue; } }
Created attachment 72455 [details] Patch
Comment on attachment 72455 [details] Patch No way to test this? Do mac and win port do the same?
(In reply to comment #6) > (From update of attachment 72455 [details]) > No way to test this? > Do mac and win port do the same? The change to the casing of the mime-type returned by the test plugin tests it.
Attachment 72455 [details] did not build on gtk: Build output: http://queues.webkit.org/results/4865086
(In reply to comment #6) > Do mac and win port do the same? Looking at PluginPackage::fetchInfo() for Mac and Win, yes it does.
Comment on attachment 72455 [details] Patch r=me, with the Gtk build fixed.
Created attachment 72460 [details] Patch
Created attachment 72461 [details] Patch
Comment on attachment 72461 [details] Patch Clearing flags on attachment: 72461 Committed r71006: <http://trac.webkit.org/changeset/71006>
All reviewed patches have been landed. Closing bug.