Bug 36815

Summary: [Qt] [Gtk] Plug-ins having upper case in mime type are failing to load
Product: WebKit Reporter: Paanky <maharana.pankaj>
Component: WebKitGTKAssignee: Nobody <webkit-unassigned>
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   
Description Flags
Patch none

Description Paanky 2010-03-30 05:07:07 PDT
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);"
Comment 1 Alexey Proskuryakov 2010-03-30 12:45:49 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.
Comment 2 Paanky 2010-04-01 12:16:28 PDT
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.
Comment 3 Paanky 2010-05-13 22:10:42 PDT
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.
Comment 4 Paanky 2010-06-21 23:04:42 PDT
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))

   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)){
Comment 5 Robert Hogan 2010-10-31 05:56:44 PDT
Created attachment 72455 [details]
Comment 6 Antonio Gomes 2010-10-31 06:21:43 PDT
Comment on attachment 72455 [details]

No way to test this?
Do mac and win port do the same?
Comment 7 Robert Hogan 2010-10-31 06:48:22 PDT
(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.
Comment 8 WebKit Review Bot 2010-10-31 06:49:44 PDT
Attachment 72455 [details] did not build on gtk:
Build output: http://queues.webkit.org/results/4865086
Comment 9 Robert Hogan 2010-10-31 06:51:54 PDT
(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 10 Antonio Gomes 2010-10-31 07:00:12 PDT
Comment on attachment 72455 [details]

r=me, with the Gtk build fixed.
Comment 11 Robert Hogan 2010-10-31 09:38:44 PDT
Created attachment 72460 [details]
Comment 12 Robert Hogan 2010-10-31 09:41:33 PDT
Created attachment 72461 [details]
Comment 13 WebKit Commit Bot 2010-10-31 19:48:52 PDT
Comment on attachment 72461 [details]

Clearing flags on attachment: 72461

Committed r71006: <http://trac.webkit.org/changeset/71006>
Comment 14 WebKit Commit Bot 2010-10-31 19:48:59 PDT
All reviewed patches have been landed.  Closing bug.