Open http://wickedgoodgames.com/java.shtml and click on a game Actual results: Black screen Works in 64-bit mode. Tested on Mac 10.7.5, 10.8.2 - FF 18b5, nightly 2012-12-20.
I forgot to mention to open FF in 32-bit mode first.
Is this a regression?
Don't know exactly, I couldn't reproduce on another clean Mac OS X 10.8.2 image. But I managed to reproduce on another Mac OS X 10.7 machine. Investigating...
It doesn't seem to be a regression... It might be something related to the latest j7u10 update. Can you please try to see if you're able to reproduce?
For me on OSX 10.8.2, Java 7u9, it refuses to load because it is only 64bit. What are the results for you when entering the following in the terminal: file /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/MacOS/JavaAppletPlugin Does it show a proper "plugin missing" notification etc. when you delete the pluginreg.dat from your profile before starting FF in 32bit?
(In reply to Georg Fritzsche [:gfritzsche] [away Dec 24 - Jan 1] from comment #5) > For me on OSX 10.8.2, Java 7u9, it refuses to load because it is only 64bit. > > What are the results for you when entering the following in the terminal: > file /Library/Internet\ > Plug-Ins/JavaAppletPlugin.plugin/Contents/MacOS/JavaAppletPlugin /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/MacOS/JavaAppletPlugin: Mach-O 64-bit dynamically linked shared library x86_64 > Does it show a proper "plugin missing" notification etc. when you delete the > pluginreg.dat from your profile before starting FF in 32bit? I don't see any notification.
Related to bug 821304?
> Related to bug 821304? Very unlikely. Here's my guess at this point: We worked hard to get 32-bit plugins to work (running OOP) with FF running in 64-bit mode. And though I suspect we intended to allow 64-bit plugins to work with FF running in 32-bit mode, I doubt we ever tested it. This is probably the first time the issue has come up. And no, I won't have any time to work on this before next year.
Oops, please disregard what I said in comment #8. I forgot that the Java plugin actually runs in-process. We'll never be able to support running a 64-bit plugin in-process while FF is running in 32-bit mode (or vice versa).
We did not intend, nor do we intend, for 64-bit plugins to work in a 32-bit Firefox. If that is the case here, then it is WONTFIX.
Failing to load the 64bit Java plugin into 32bit FF is what i see on my machine and Pauls comment confirms that. However, we don't show any "missing plugin error" notification or something similar. We might want to reject the plugin when scanning the plugin dirs or show a proper error when we fail to instantiate it.
We should reject the plugin when scanning, yes.
Simply rejecting seems easy enough. Waiting for the try build because universal builds take too long here: https://tbpl.mozilla.org/?tree=Try&rev=c3b76f0885ee http://email@example.com
Assignee: nobody → georg.fritzsche
Status: NEW → ASSIGNED
Comment on attachment 694528 [details] [diff] [review] Reject plugins with a different architecture in 32bit Mac builds That build looks good.
Comment on attachment 694528 [details] [diff] [review] Reject plugins with a different architecture in 32bit Mac builds Looks fine to me. I've no objection to not supporting 64-bit plugins from 32-bit Firefox. Our support for running FF in 32-bit mode is obsolescent, and we'd eventually like to drop it altogether. Or at least that's my understanding.
Attachment #694528 - Flags: review?(smichaud) → review+
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
Ok, so now after switching to 32-bit mode, Java is no longer listed in addons/plugins and the "missing plugins" notification appears when trying to open a java applet. I would say the notification is a little bit confusing, wouldn't be better to really explain to the user what's going on with java ?
That notification is what's expected. Any more specific notification would require more work, so i don't think we want to go there given that 32-bit builds on Mac are not the priority anyway.
You need to log in before you can comment on or make changes to this bug.