Java applet fails to load



Core Graveyard
Java: OJI
11 years ago
7 years ago


(Reporter: Amos Hayes, Assigned: Josh Aas)


({fixed1.8.0.5, fixed1.8.1})

1.8 Branch
Mac OS X
fixed1.8.0.5, fixed1.8.1
Bug Flags:
blocking1.8.0.5 +

Firefox Tracking Flags

(Not tracked)



(2 attachments)



11 years ago
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: Gecko/20060626 Firefox/
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

11 years ago
Created attachment 227413 [details]
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

11 years ago
Created attachment 227415 [details]
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".
Any chance to get a test case?
I tried a couple of signed Java applets (one of my own and one
available online) with the latest Firefox 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  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 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

11 years ago
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

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

11 years ago
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

11 years ago
Sorry. I meant to say that the file created by Java Preferences is "" in ~/Library/Preferences.
So deleting or renaming 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 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).
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 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

11 years ago
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

11 years ago
Adding relnote keyword. It's all gavin's fault.

Suggested text:

In Firefox on Apple OS X, the "Plugin Version" parameter of the 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 file to the main "/Library/Preferences" folder.
Keywords: relnote
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:

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 browser(s).

I doubt that I've released it in time for Firefox  But I do
hope to get it into BonEcho Beta 1.
Depends on: 343180
Let's see what drivers think, there might still be time to fix this regression and keep it from affecting

Drivers: a change in the way that the JEP picks JVM versions makes for some quite confusing behaviour in the 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!
Flags: blocking1.8.1?
Flags: blocking1.8.0.6?
Flags: blocking1.8.0.5?

Comment 14

11 years ago
shaver, I tested and it solves the problem.

I deleted 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 ( 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.
Great, thanks.  If we can't get this taken into to avoid the regression, we should at least mention the JEP update in the relnote.
Josh, can we get the new JEP landed ASAP? We'd like today to be our final respin.
Assignee: yuanyi21 → joshmoz
Flags: blocking1.8.0.6?
Flags: blocking1.8.0.5?
Flags: blocking1.8.0.5+
This ought to be fixed by the new JEP from but 343180, please verify.
Last Resolved: 11 years ago
Keywords: fixed1.8.0.5, fixed1.8.1
Resolution: --- → FIXED

Comment 18

11 years ago
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: Gecko/20060706 Firefox/


11 years ago
Keywords: relnote
Summary: Java applet failes to load → Java applet fails to load
Flags: blocking1.8.1?


7 years ago
Component: Java: OJI → Java: OJI
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.