29.73 KB, image/png
96.50 KB, image/png
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:188.8.131.52) Gecko/20060626 Firefox/184.108.40.206 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.
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".
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 220.127.116.11 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 18.104.22.168) 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.)
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.
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.
Sorry. I meant to say that the file created by Java Preferences is "com.apple.java.JavaPreferences.plist" in ~/Library/Preferences.
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).
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.
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?
Adding relnote keyword. It's all gavin's fault. Suggested text: In Firefox 22.214.171.124 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.
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 126.96.36.199. But I do hope to get it into BonEcho Beta 1.
Let's see what drivers think, there might still be time to fix this regression and keep it from affecting 188.8.131.52. Drivers: a change in the way that the JEP picks JVM versions makes for some quite confusing behaviour in the 184.108.40.206 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!
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 (220.127.116.11 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 18.104.22.168 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.
This ought to be fixed by the new JEP from but 343180, please verify.
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:22.214.171.124) Gecko/20060706 Firefox/126.96.36.199