RESOLVED FIXED 36815
[Qt] [Gtk] Plug-ins having upper case in mime type are failing to load
https://bugs.webkit.org/show_bug.cgi?id=36815
Summary [Qt] [Gtk] Plug-ins having upper case in mime type are failing to load
Paanky
Reported Tuesday, March 30, 2010 1:07:07 PM UTC
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);"
Attachments
Patch (4.31 KB, patch)
2010-10-31 05:56 PDT, Robert Hogan
no flags
Patch (4.33 KB, patch)
2010-10-31 09:38 PDT, Robert Hogan
no flags
Patch (4.33 KB, patch)
2010-10-31 09:41 PDT, Robert Hogan
no flags
Alexey Proskuryakov
Comment 1 Tuesday, March 30, 2010 8:45:49 PM UTC
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.
Paanky
Comment 2 Thursday, April 1, 2010 8:16:28 PM UTC
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.
Paanky
Comment 3 Friday, May 14, 2010 6:10:42 AM UTC
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.
Paanky
Comment 4 Tuesday, June 22, 2010 7:04:42 AM UTC
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; } }
Robert Hogan
Comment 5 Sunday, October 31, 2010 1:56:44 PM UTC
Antonio Gomes
Comment 6 Sunday, October 31, 2010 2:21:43 PM UTC
Comment on attachment 72455 [details] Patch No way to test this? Do mac and win port do the same?
Robert Hogan
Comment 7 Sunday, October 31, 2010 2:48:22 PM UTC
(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.
WebKit Review Bot
Comment 8 Sunday, October 31, 2010 2:49:44 PM UTC
Robert Hogan
Comment 9 Sunday, October 31, 2010 2:51:54 PM UTC
(In reply to comment #6) > Do mac and win port do the same? Looking at PluginPackage::fetchInfo() for Mac and Win, yes it does.
Antonio Gomes
Comment 10 Sunday, October 31, 2010 3:00:12 PM UTC
Comment on attachment 72455 [details] Patch r=me, with the Gtk build fixed.
Robert Hogan
Comment 11 Sunday, October 31, 2010 5:38:44 PM UTC
Robert Hogan
Comment 12 Sunday, October 31, 2010 5:41:33 PM UTC
WebKit Commit Bot
Comment 13 Monday, November 1, 2010 3:48:52 AM UTC
Comment on attachment 72461 [details] Patch Clearing flags on attachment: 72461 Committed r71006: <http://trac.webkit.org/changeset/71006>
WebKit Commit Bot
Comment 14 Monday, November 1, 2010 3:48:59 AM UTC
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.