342997 - Java applet fails to load

Status: VERIFIED FIXED

(Core Graveyard :: Java: OJI, defect)

Description

[Amos Hayes]

I'm getting Applet Not Loaded messages and my self-signed applet is failing to load after clicking "Yes" through the Verify Certificate dialog on the following:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.5) Gecko/20060626 Firefox/1.5.0.5
Also got same result on a self-built version of the 1.8.0 branch from June 18th.

The June 13th Deer Park nightly did not have this problem. I will try to narrow it down further.

Interestingly, turning on the Java Console (Applications -> Utilities -> Java -> J2SE 5.0 -> Java Preferences under theAdvanced tab) and restarting causes the security dialog to change when I try again. Clicking "Trust" works and then the applet loads correctly.

Comment 1

[Amos Hayes]

Attachment: Java dialog when console is off (applet fails to load)

Attached screenshot of security dialog with console off. The applet then fails to load even if I click "Yes".

Comment 2

[Amos Hayes]

Attachment: Java dialog when console is on (applet then loads correctly)

Attached screenshot of security dialog with console on. The applet then loads correctly after clicking "Trust".

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Any chance to get a test case?

Comment 4

[Steven Michaud [:smichaud] (Retired)]

I tried a couple of signed Java applets (one of my own and one
available online) with the latest Firefox 1.5.0.5 rc1 (dated 6-27-06),
and I'm not able to reproduce your results.  Furthermore, I suspect
your problem (whatever it is) has nothing to do with whether or not
your applet is signed.

The online example is at http://segal.org/java/hellotrust/.  Are you
able to reproduce your problem with this.  Let us all know ... but I
suspect not.

Note that (in a browser (e.g. Firefox 1.5.0.4) where your problem
doesn't occur) the hellotrust applet still loads even when you choose
not to "trust" it -- it just no longer has the privileges to escape
the Java "sandbox".

I suggest that you fiddle with your applet to try to isolate the
problem.  The first thing to try (of course) is to create a non-signed
version of it, and see what happens.  Once you have isolated the
problem, please post the source code for a test case.

(I tested with Java 5.0 and 1.4.2 on OS X 10.4.6, and with Java 1.4.2
on OS X 10.3.9.)

Comment 5

[Amos Hayes]

I have not been able to reproduce the problem on any system for which the console has ever been turned on; however, I can reproduce the problem on fresh systems with my applet. I do not see the problem with the applet at http://segal.org/java/hellotrust/

Can anyone think of something that changes permanently (i.e. not cleared by deleting cache, profile, restart, etc) as a result of having ever turned the console on? Because the dialog is changing as a result of the console having been turned on and that change is affecting whether my applet runs or not. I will see if I can boil things down to a test case.

Comment 6

[Amos Hayes]

OK. More info. The change in behaviour (for the better) occurs after opening and quitting Java Preferences *without changing anything*.

After some analysys, it looks like just by opening J2SE 5.0 Java Preferences, a file is created that sets "NSTreatUnknownArgumentsAsOpen" to "NO". Changing "NO" to "YES" causes my applet to fail to load.

Any ideas? Firefox's treatment of this variable appears to have changed between approximately June 13th and June 18th.

Comment 7

[Amos Hayes]

Sorry. I meant to say that the file created by Java Preferences is "com.apple.java.JavaPreferences.plist" in ~/Library/Preferences.

Comment 8

[Steven Michaud [:smichaud] (Retired)]

So deleting or renaming com.apple.java.JavaPreferences.plist causes
your problem to start happening again?

And why do you conclude that NSTreatUnknownArgumentsAsOpen is the
crucial setting?

Here's my hunch:  The crucial setting in that file is "Plugin Version"
(which is the only other setting in my copy of that file).  When the
com.apple.java.JavaPreferences.plist file is absent, the Java
Embedding Plugin defaults to selecting Java 1.4.2.  My guess is that
your applet expects Java 5.0/1.5, and chokes when it finds that it's
running in the "wrong" version.

Or maybe the problem has nothing to do with your applet per-se -- it's
just that you've used the Java 5.0 version of javac to compile it
(this is what XCode now does by default on Tiger (with J2SE 5.0
Release 4 installed), unless you tell it to do otherwise).  If you try
to run such an applet in Java 1.4.2, you get the following error:

java.lang.UnsupportedClassVersionError: Access (Unsupported major.minor version 49.0)
        at java.lang.ClassLoader.defineClass0(Native Method)
        ...

You could argue that the Java Embedding Plugin should default to Java
5.0/1.5 (as Apple's JVM does when it runs in Safari).  In fact I now
think that's how the JEP should behave.  I'll change it to default to
Java 5.0/1.5 in the next release (though of course it will still be
possible to use Java Preferences to explicitly select Java 1.4.2).

Comment 9

[Steven Michaud [:smichaud] (Retired)]

Side note:  The Java Embedding Plugin was upgraded to 0.9.5+e on the
1.8.0 branch (the branch for Firefox 1.5.0.X) on (I think) 2006-06-14.
Prior versions (when used with Apple's J2SE 5.0 Release 4, which is
their current Java release) always used Java 5.0/1.5, regardless of
the Java Console setting (and regardless of the presence or absence of
the com.apple.java.JavaPreferences.plist file).  JEP 0.9.5+e obeys the
"Plugin Version" setting in that file, but (as I've said) defaults to
Java 1.4.2 in its absence.

So if my hunch from comment #8 is right, it also explains your
regression window.

Comment 10

[Amos Hayes]

Thanks for sorting that out Steven. I was mistaken in my testing of NSTreatUnknownArgumentsAsOpen. I can confirm that the behaviour you describe is what I'm seeing. Our applet does indeed require J2SE 5.0. That also explains the different trust dialogs.

I think that in the abscence of the "Plugin Version" setting, it should default to the latest version available on the system. I imagine a user would expect to see a new Java version used automatically after installing it... assuming Plugin Version isn't explicitly set.

Note that OS X 10.3.x and below do not have J2SE 5.0 so Firefox should maintain a way to fall-back to JRE 1.4.2.

Thanks for your help. Could this change in behaviour and the fix be documented in the release notes?

Comment 11

[Amos Hayes]

Adding relnote keyword. It's all gavin's fault.

Suggested text:

In Firefox 1.5.0.5 on Apple OS X, the "Plugin Version" parameter of the com.apple.java.JavaPreferences.plist file is now respected. If it is not present, then Java 1.4.2 will be used. In order to use the J2SE 5.0 plugin on a normal installation of Apple OS X 10.4 Tiger, run and then quit the "Java Preferences" application located in "/Applications/Utilities/Java/J2SE 5.0/". This will create the preferences file with the correct setting in your user's "~Library/Preferences" folder. To set this new default for all users, copy the generated com.apple.java.JavaPreferences.plist file to the main "/Library/Preferences" folder.

Comment 12

[Steven Michaud [:smichaud] (Retired)]

I've just released a new version (0.9.5+f) of the Java Embedding
Plugin that defaults to Java 5.0/1.5 on OS X 10.4.X with J2SE 5.0
Release 4 installed, and (in a way) resolves this bug:

http://javaplugin.sourceforge.net/

Please follow the Readme's instructions to install the new JEP to your
/Library/Internet Plug-Ins/ folder, and to remove older copy(ies) of
the JEP from your Mozilla.org browser(s).

I doubt that I've released it in time for Firefox 1.5.0.5.  But I do
hope to get it into BonEcho Beta 1.

Comment 13

[Mike Shaver (:shaver emeritus)]

Let's see what drivers think, there might still be time to fix this regression and keep it from affecting 1.5.0.5.

Drivers: a change in the way that the JEP picks JVM versions makes for some quite confusing behaviour in the 1.5.0.5 candidate, which will likely also make for a fair bit of bugnoise and possibly reluctance to upgrade (or a bad taste left after the upgrade).  Taking the fixed JEP should be pretty low risk, from a scan of the changes, but if we have some additional Java tests we can run on the Mac so much the better!

Amos: can you confirm that the new JEP resolves your issue?  Thanks!

Comment 14

[Amos Hayes]

shaver, I tested and it solves the problem.

I deleted com.apple.java.JavaPreferences.plist from ~/Library/Preferences and confirmed that there was not a copy in /Library/Preferences.

I used the same version of Firefox that was giving me grief before (1.5.0.5 rc1) and replaced the JavaEmbeddingPlugin.bundle and MRJPlugin.plugin files in Firefox/Contents/MacOS/plugins from the JavaEmbeddingPlugin0.9.5+f package.

I loaded my applet, was prompted with the Java 5 trust dialog, accepted, and then everythign worked.

Comment 15

[Mike Shaver (:shaver emeritus)]

Great, thanks.  If we can't get this taken into 1.5.0.5 to avoid the regression, we should at least mention the JEP update in the relnote.

Comment 16

[Daniel Veditz [:dveditz]]

Josh, can we get the new JEP landed ASAP? We'd like today to be our final respin.

Comment 17

[Daniel Veditz [:dveditz]]

This ought to be fixed by the new JEP from but 343180, please verify.

Comment 18

[Amos Hayes]

I built and tested MOZILLA_1_8_0_BRANCH from CVS this afternoon and confirm that the problem I reported is fixed.

Deer Park
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.5) Gecko/20060706 Firefox/1.5.0.5