Summary: | [Qt] [Gtk] Plug-ins having upper case in mime type are failing to load | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Paanky <maharana.pankaj> | ||||||||
Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> | ||||||||
Status: | RESOLVED FIXED | ||||||||||
Severity: | Major | CC: | ap, commit-queue, gustavo, maharana.pankaj, robert, webkit.review.bot, xan.lopez | ||||||||
Priority: | P2 | ||||||||||
Version: | 528+ (Nightly build) | ||||||||||
Hardware: | All | ||||||||||
OS: | Linux | ||||||||||
Attachments: |
|
Description
Paanky
2010-03-30 05:07:07 PDT
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. |