630285 - Java Applet version detection broken in Firefox 4

Status: RESOLVED INCOMPLETE

(Plugins Graveyard :: Java (Apple), defect)

Description

[Jean Pierre Wenzel]

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b10) Gecko/20100101 Firefox/4.0b10
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b10) Gecko/20100101 Firefox/4.0b10

Firefox is not displaying a Java applet if it is explicitly asking for a specific Java version, e.g., 1.4 or 1.6. It does (fascinating!), however, work with version 1.5.

The Java applets used to work perfectly fine in Firefox 3.6.13.

Please see the testcases attached to this bug (all of them are linked to in index.html).

Reproducible: Always

Steps to Reproduce:
Open index.html in attached test case ZIP file and follow the links to the test cases.
Actual Results:  
* Java Applet without explicitely specifying the version -> works as expected
* Java Applet (version 1.4) -> broken
* Java Applet (version 1.5) -> works as expected
* Java Applet (version 1.6) -> broken
* Java Applet (not existing version 3.141592654) -> works as expected

Expected Results:  
Java Applets with the requested version 1.4 and 1.6 should have been displayed as Java version 1.6.0_22 is installed.

Mac OS X 10.6.6

% java -version
java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04-307-10M3261)
Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03-307, mixed mode)

Comment 1

[Jean Pierre Wenzel]

Attachment: Test cases mentioned in this bug report.

Comment 2

[Fred Wenzel [:wenzel]]

I can confirm this. The problematic part is not that 1.4 does not work (if the site asks for 1.4 and only 1.6 is present, then showing "plugin needed" is arguably expected behavior or at least explainable). However, if asking for 1.6 does not work, and 1.6.0_22 is present, then that's a bug and will result in websites not working that do follow this pattern.

This is not theoretical: One of the sites that's broken with Firefox 4 due to this bug is the German postal service's online postage printing website, likely to be used by a nontrivial amount of Firefox users in Germany.

Comment 4

[Jean Pierre Wenzel]

More information on the version selection mechanism of the new implementation of the Java plugin:
http://www.oracle.com/technetwork/java/javase/index-141751.html#JAVA_VERSION

Quote:
------------------------------------------------------------
[…] a limited degree of backward compatibility is supported in the new Java Plug-In. Specifically, the version attribute is supported to request an arbitrary JRE in a given family or any later family.

Note that this backward compatibility mechanism may be removed in a future release. […] To use the version attribute to require the 1.5 JRE or a later one: 

<embed code="MyApplet" type="application/x-java-applet;version=1.5"
  width="200" height="200">
</embed>

[…]

Note that the semantics of the version attribute imply that the above tag is equivalent to using the java_version parameter with a value of 1.5+. Since the new Java Plug-In is delivered with Java SE 6 update 10, which is a later version than 5.0, this version request essentially has no effect.
------------------------------------------------------------

Comment 5

[Jean Pierre Wenzel]

(In reply to comment #2)
> I can confirm this. The problematic part is not that 1.4 does not work (if the
> site asks for 1.4 and only 1.6 is present, then showing "plugin needed" is
> arguably expected behavior or at least explainable)

According to Oracle's spec (see the quote), in this case the Java 1.6 runtime (which *is* installed and detected) should run the applet.

Comment 6

[Jean Pierre Wenzel]

In about:plugins under "Java Plug-In 2 for NPAPI Browsers", the

    application/x-java-applet;version=1.4
    application/x-java-applet;version=1.6

MIME types are not listed while

    application/x-java-applet;version=1.5

actually is.

This might explain why the applet in the test cases works fine as long as Java version 1.5 is requested.

Comment 7

[Gnonthgol]

I might mention that the problem does not exist on Firefox 3.5 as it have the application/x-java-applet;version=1.6 entry in about:plugins in addition to many more entries witch are missing in 4.0.

I wonder what the changes that has been made to the plugin loading that prevents all those entries to be loaded?

Comment 8

[Steven Michaud [:smichaud] (Retired)]

Please test to see if this problem also exists in Safari when it uses
Java Plugin2 (as FF4 now does on OS X).

To make Safari use Java Plugin2:

1) Run Applications : Utilities : Java Preferences
2) Choose to "Run applets" "In their own process"

If this problem also exists in Safari, it's Apple's bug, and should be
made to block bug 554103.

Comment 9

[Jean Pierre Wenzel]

I just tested the behavior in Safari.app: The applet loads fine for all Java versions from the tests -- it does not even fail for the Java version "pi" (3.141…) which I made up, but I guess *that* is Apple's problem. :)

Comment 10

[Fred Wenzel [:wenzel]]

Based on comment 0 and comment 7, this is a regression in Fx4 only.

Comment 11

[Steven Michaud [:smichaud] (Retired)]

I'm not going to be able to get to this for a while -- I've got two
big, nasty, complex bugs ahead of it in my queue (bug 626016/bug
629593 and bug 627649).

Comment 12

[Steven Michaud [:smichaud] (Retired)]

Possibly related to bug 604041.

Comment 13

[Steven Michaud [:smichaud] (Retired)]

Big, nasty, complex *blocker* bugs.

Comment 14

[Benjamin Smedberg]

Is this mac-only? IIRC we made a change for mac plugins so that we don't call NPP_GetMIMEDescription for plugins which provide MIME types via their plist. Is it possible that the Java bundle returns different information in the plist than it did from NPP_GetMIMEDescription?

According to the plist, these MIME types are supported by the Java plugin:

Java Plug-In 2 for NPAPI Browsers

    File: JavaPlugin2_NPAPI.plugin
    Version: 13.3.0
    Java Plug-In 2 for NPAPI Browsers

MIME Type 	Description 	Suffixes
application/x-java-applet;version=1.1.3 	Java applet 	
application/x-java-applet 	Basic Java Applets 	javaapplet
application/x-java-applet;jpi-version=1.6.0_22 	Java applet 	
application/x-java-applet;version=1.2.2 	Java applet 	
application/x-java-applet;version=1.5 	Java applet 	
application/x-java-applet;version=1.3.1 	Java applet 	
application/x-java-applet;version=1.3 	Java applet 	
application/x-java-vm 	Java applet 	
application/x-java-applet;version=1.1.2 	Java applet 	
application/x-java-applet;version=1.1 	Java applet

Obviously since ;version=1.6 is not listed, we don't support it. This sounds like a plugin bug, but it might be something we have to work around.

Comment 15

[Benjamin Smedberg]

The Java plugin doesn't list ;version=1.6 in their Info.plist, and they don't implement NPP_GetMIMEDescription/NP_GetMIMEDescription. I believe this is simply a bug in JavaPlugin2_NPAPI.

Comment 16

[Steven Michaud [:smichaud] (Retired)]

> The Java plugin doesn't list ;version=1.6 in their Info.plist, and
> they don't implement NPP_GetMIMEDescription/NP_GetMIMEDescription.
> I believe this is simply a bug in JavaPlugin2_NPAPI.

I agree.

Safari must somehow work around this, but it's still an Apple bug.

Comment 17

[Gnonthgol]

> I agree.
> 
> Safari must somehow work around this, but it's still an Apple bug.

It seems to be a bug in Apple, but Safari, Opera and even FF 3.6 works around
this so users might see it as a FF bug. This should be reported to Apple and if
there is no reason why the workaround used in 3.6 should not be used in 4.0 I
suggest we keep it in until we are certain all systems have been upgraded.

Comment 18

[Steven Michaud [:smichaud] (Retired)]

Firefox 3.6 (and 3.5) use a different Java Plugin on OS X (the Java
Embedding Plugin), so what they do isn't relevant to this bug.  (And
FF4 has changed sufficiently that it can no longer use the JEP.)

Opera (11.01) does use Java Plugin2 on OS X.  I haven't had a chance
to check whether Opera is effected by this bug.

Comment 19

[Sierk Bornemann]

FYI:

Apple has released 3 new Developer Previews for Java Update,
Java for Mac OS X Developer Preview 10M3308+9M3308 (December 13, 2010)
Java for Mac OS X Developer Preview 10M3310+9M3310 (January 6th, 2011)
Java for Mac OS X Developer Preview 10M3314+9M3314 (January 26th, 2011)

updating J2SE 5.0 to 1.5.0_26 and updating Java SE 6 to 1.6.0_23.

Main focus for testing: interaction of Plugin2 with applets and browsers.

If not done yet, please install and test the latest of these developer seeds and read carefully the belonging release notes with extra focus on Plugin2 and so far known issues/known problems using it with Safari, Firefox 3.6 and Firefox 4.

Mike Swingler's (Java Engineering, Apple Inc) announcement concerning the latest Java Developer Preview on Apple's public java-dev mailinglist from Thu, 27 Jan 2011:

Apple Mailinglist java-dev: Java for Mac OS X Developer Preview (10M3314+9M3314)
http://lists.apple.com/archives/java-dev/2011//Jan/msg00132.html

Comment 20

[Steven Michaud [:smichaud] (Retired)]

Warning:  Don't install these Developer Previews on a "production system".

This is what Apple recommends.  And I've gotten in trouble for not following this advice.  (I've seen others get in trouble, too.)

Comment 21

[Gnonthgol]

> Opera (11.01) does use Java Plugin2 on OS X.  I haven't had a chance
> to check whether Opera is effected by this bug.

Opera 11.01 seems to use the same Java Plugin2 as FF does and reports the same
mime types as Java Plugin2 on FF 3.6

I tested the new java plugin supplied by apple and it reported even fewer mime
types while Opera still shows the same list as before the version bump.

Comment 22

[Steven Michaud [:smichaud] (Retired)]

Testing with Jean Pierre's testcase from comment #1, I've confirmed
that Opera 11.01 isn't effected by this bug (at least on OS X 10.6.6).
It also (unlike Safari) correctly refuses to honor a request for
version 3.141592654.

So Opera does work around this bug.  And we should consider doing so,
too.

But like I said, I've got other, more urgent bugs that will occupy me
for a while -- possibly as long as the next two weeks.

Comment 23

[Steven Michaud [:smichaud] (Retired)]

And yes, I've also confirmed that Opera 11.01 uses Java Plugin2.

Comment 24

[Steven Michaud [:smichaud] (Retired)]

(From comment #2)

> This is not theoretical: One of the sites that's broken with Firefox
> 4 due to this bug is the German postal service's online postage
> printing website, likely to be used by a nontrivial amount of
> Firefox users in Germany.

Many sites that request a particular Java version don't really need
to.  (And bug 604041 has an example of a site that clearly requests an
inappropriate Java version -- version 1.4, which is long obsolete.)

It may be worth approaching them about this (though I certainly don't
have the time to do so, or any knowledge of German).

Comment 25

[Gnonthgol]

> Many sites that request a particular Java version don't really need
> to.  (And bug 604041 has an example of a site that clearly requests an
> inappropriate Java version -- version 1.4, which is long obsolete.)

Do note that setting version=1.4 requests Java version 1.4 or newer. If the applet is tested with java versions from 1.4 to 1.6 this is the correct behaviour for the sites.

Comment 26

[Sierk Bornemann]

(In reply to comment #20)
> Warning:  Don't install these Developer Previews on a "production system".

Maybe you are not aware of the fact, that Apple has changed it's Java package since their latest regular Java update to that fact, that you no can install multiple developer packages and JDK packages from other vendors like OpenJDK in parallel to your system's installation WITHOUT overwriting/deleting or touching it, simply that another further .jdk-bundle besides the systems's 1.6.0.jdk-bundle is placed under /System/Library/Java/JavaVirtualMachines, and you can switch/toggle between these bundles and JDKs (for instance your stable system's installation, your developer preview, a JDK7 bundle etc. pp.) with your Java Preference Utility /Applications/Utilities/Java Preferences.app.

See the screenshot on http://code.google.com/p/openjdk-osx-build/ of how it may look like, and how you may switch between Apples stable system's JDK and Apples developer's JDK or maybe other installed vendor's JDK.

And you can, for the first time, also delete/remove your additional installed bundle (Apples developer builds also carrie the Java headers and the Java docs within its .jdk-bundle) from the JavaVirtualMachines-directory simply by deleting it (for instance dragging it into the Trashcan).

>This is what Apple recommends.

Yes, and I don't see any problem with it, because as far as I can see, since Apples last regular Java Update in October 2010, all possible jdk-bundles may be installed in parallel without disturbing or overwriting each other to be able to switch/toggle between them. And make it for developers like you and me easier to test. :-) So like on other platforms (Windows, Linux) it is possible and used since years. System's JDK is not touched until Apple ships a new regular Java update or overwrites it via the system's regular software update.

Comment 27

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #25)

> Do note that setting version=1.4 requests Java version 1.4 or newer.

OK, I didn't realize this.  I stand partly corrected.

But if version 1.4 is long obsolete, it has for a long time not been
necessary for this particular site to specify any Java version -- all
current versions now have the desired behavior (whatever that is).

Comment 28

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #26)

I wasn't aware of this.  Sounds like good news.

Still pays to be cautious, though.

Comment 29

[Jean Pierre Wenzel]

(In reply to comment #24)
> (From comment #2)
> 
> > This is not theoretical: One of the sites that's broken with Firefox
> > 4 due to this bug is the German postal service's online postage
> > printing website, likely to be used by a nontrivial amount of
> > Firefox users in Germany.
> 
> It may be worth approaching them about this (though I certainly don't
> have the time to do so, or any knowledge of German).

I happen to speak German so I'm going to take care of that. Let's see if I can convince DHL to update their HTML code to use the java_version attribute in the <embed> tag as a workaround, as this seems to work fine. I'm currently updating the test cases and will upload them here when done.

Regarding the version=… values, let me give a few examples to clarify:

* version=1.4 => You'll need have at least a 1.4 Java Runtime Environment (JRE) installed to be able to use this applet. If you're opening the applet on your 1998 Java 1.2 machine, you're on your own.
* version=1.4* => You'll need *any* 1.4 JRE. Nothing else, not even a newer one!
* version=1.4+ => You'll be fine if you have any JRE installed, as long as it's version 1.4 or newer.

So, "version=1.4" is the oldest JRE version which is supported by the DHL applet.

Comment 30

[Jean Pierre Wenzel]

Attachment: Updated test cases, including expected and actual behavior.

Updated test cases (expected and actual behavior). Tests performed on Firefox 4 Beta 10 (Mac OS X 10.6.6). Java version 1.6.0_22.

Comment 31

[Steven Michaud [:smichaud] (Retired)]

This may have been fixed by the patch for bug 638171 (and if so this bug is a dup of bug 638171).

Please test with a current mozilla-central and/or mozilla-2.0 nightly (ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/).

Comment 32

[Benjamin Smedberg]

Closing old bugs in the Plugins component. We aren't going to track issues in 3rd-party plugins in the Mozilla bug tracker. In addition, support for NPAPI plugins will be removed at the end of this year; for more details see the post at https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/

If there is a serious bug in Firefox, it needs to be filed in the "Core" product, "Plug-Ins" component.