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.)