Re: MIME type parameters

Jack Bates <[email protected]> Wed, 08 Jan 2014 09:25:13 -0800
Newsgroups gmane.comp.mozilla.devel.plugins
Message-ID <[email protected]>
On 08/01/14 07:26 AM, Benjamin Smedberg wrote:
> On 1/7/2014 6:38 PM, Jack Bates wrote:
>> Should nsPluginHost::FindPluginForType() ignore MIME type parameters
>> when it searches for matching plugins?
> No. Java registers separate plugins with parameters for e.g. different
> versions of Java:
>
> application/x-java-applet;version=1.1.1

Thank you, actually I asked about this because of a problem with the 
IcedTea-Web Java plugin:

http://thread.gmane.org/gmane.comp.java.openjdk.distro-packaging.devel/25666

I am unable to access certain webapps (Oracle Forms) with Firefox on 
Ubuntu because they use MIME type
application/x-java-applet;jpi-version=1.6.0_06

The IcedTea-Web Java plugin NP_GetMIMEDescription() returns
application/x-java-applet;jpi-version=1.6.0_50

So Firefox complains "A plugin is needed to display this content."

(I am unable to modify the webapps.)

The new (Java SE 6 update 10) Sun (Oracle) Java plugin version selection 
behavior is:

When considering a request to launch an applet on a specific JRE version 
(for example, a particular update release like "1.5.0_11"):

The list of available JREs is consulted. If there is an exact match of 
the version string, that JRE version is selected. Otherwise, if there 
are one or more installed JREs in the same family, the latest version is 
selected. Otherwise, the latest available JRE on the machine is selected.

http://www.oracle.com/technetwork/java/javase/index-141751.html#BEHAVIOR

If I apply the patch from Jiri Vanek
([email protected] thread: add
application/x-java-applet;jpi-version=1.6.0_06 to 
NP_GetMIMEDescription()) and rebuild IcedTea-Web, then I can 
successfully access the Oracle Forms webapps with Firefox.

How can we achieve the documented version selection behavior, without 
hardcoding a generated list of every update release into 
NP_GetMIMEDescription() (which Jiri Vanek says "will look in 
about:plugins even more terrible than current looong list)?

(The only alternatives I can think of are wildcard support in 
nsPluginHost::FindPluginForType() or ignoring MIME type parameters and 
delegating them to the plugin.)