Closed Bug 510035 Opened 10 years ago Closed 10 years ago
Java applet does not load on Mac OS X in anything built on 1
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a2pre) Gecko/20090812 Minefield/3.6a2pre Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a2pre) Gecko/20090812 Minefield/3.6a2pre Java applets will not load on Mac OS X (10.5.8). Reproducible: Always Steps to Reproduce: 1.Visit http://www.jigzone.com/puzzles/daily-jigsaw or https://www2.bancobrasil.com.br/aapf/login.jsp 2. 3. Actual Results: First site example does lot load a puzzle game, shows a box with error text: "Oops,the puzzle has failed to start in a reasonable time. This could happen if your are no longer connected to the internet or your computer has problems displaying Java applets". Second site does not load virtual keyboard to input password (online banking) Expected Results: The first site should load a puzzle game and the second site should load a virtual keyboard to users can input password. Works on release 3.5.2
I can confirm this problem on my build. Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20090813 Minefield/3.7a1pre Built from http://hg.mozilla.org/mozilla-central/rev/8c402112ba9c
The problem occurs in Namoroka/3.6a1pre with PPC and Intel Mac. I'm not sure of the range, but this problem occurred with the trunk build after I updated to Mac OS 10.5.7 from Mac OS 10.5.6 (2009-05-14). Test page: Go to the JDK 1.4 Demo Applets from java.sun.com then chose a demo from the list, it requires a plug-in. http://java.sun.com/applets/jdk/1.4/index.html
It should be pointed out that Java is not listed in about:plugins so it's not so much that Java applets don't load, it's that the plugin itself isn't detected by Minefield. Reassigning to a more specific component will likely get this looked at faster.
I was seeing the same problem under OS X 10.4.11. When I checked /Library/Internet Plug-Ins the version of JavaEmbeddingPlugin.bundle was 0.9.2 and MRJPlugin.plugin was 1.0-JEP 0.9.2. When I checked the Contents/MacOS/plugins folder of Minefield it was empty. After installing JavaEmbeddingPlugin.bundle 0.9.7.2 and MRJPlugin.plugin 1.0-JEP 0.9.7.2 http://javaplugin.sourceforge.net/ problem solved. Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.3a1pre) Gecko/20090814 Minefield/3.7a1pre - Build ID: 20090814032252
The removal of the JEP on trunk was by design, see bug 432625.
Component: General → Plug-ins
Product: Firefox → Core
QA Contact: general → plugins
Version: unspecified → Trunk
Note that even if a recent version of the Java Embedding Plugin is present in /Library/Internet Plug-Ins/, and shows up in about:plugins, no Java applets will load. This is because OJI (needed by the JEP) has also been removed from the trunk (aka mozilla-central and FF 3.7) and from the 1.9.2 branch (aka namoroko and FF 3.6). See bug 485894. Apple and Sun have been working on porting Sun's Java Plugin2 to OS X. This is hoped for in OS X 10.6 (SnowLeopard).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Java applet does not load on Mac OS X → Java applet does not load on Mac OS X in FF 3.6 and 3.7
Oops. Namoroko -> Namoroka.
Duplicate of this bug: 504508
Steven, I'm a bit confused. In Comment #6 you state "...even if .. the Java Embedding Plugin is present ...no Java applets will load. This is because OJI (needed by the JEP has also been removed from the trunk." In your "read me" for JEP it says "The Java Embedding Plugin works at a low level -- the same as that of ... the "OJI Plugin" that Sun makes available with its Java Plugin on other platforms (but which Apple chose not to port)" implying that a) there is no Apple version of OJI and b) OJI is not needed because JEP provides the same function. If OJI is needed but not included why do Java applets work in 3.7a1 when JEP is enabled? Is it able to use the OJI from an older version of Firefox/Minefield? Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.3a1pre) Gecko/20090815 Minefield/3.7a1pre - Build ID: 20090815032547
The OJI that's been removed from the trunk (and the 1.9.2 branch, see bug 485894) is an API used by plugins (among them the JEP), not a plugin itself. > If OJI is needed but not included why do Java applets work in 3.7a1 > when JEP is enabled? Java applets don't work in 3.7a1. If the JEP is present (e.g. in /Library/Internet Plug-Ins) you won't see a missing plugin icon. But the applet will still fail to load. Try http://java.sun.com/applets/jdk/1.4/demo/applets/Clock/example1.html.
Steven, The java clock works for me in 3.7a1,(see attachment) as do the other Java demos that I tried on that site, as does http://www-archive.mozilla.org/quality/browser/front-end/testcases/oji/test1.html and http://www.time.gov/timezone.cgi?Eastern/d/-5/java
The clock's blurred hands give it away: You're running Apple's ancient Java 1.3.1 JVM! This is only possible on a PPC Mac. And many (probably most) applets still won't load, because they require a more recent JVM. Here are two examples: http://www.java.com/en/download/help/testvm.xml http://gemal.dk/browserspy/java.html I'd forgotten that the MRJPlugin.plugin included with the JEP is able to use Java 1.3.1 (where present), and when doing so doesn't use the OJI API. Apple's Java 1.3.1 hasn't been updated in many years, and is probably full of security holes. You really shouldn't be using it. I suppose we should do something to prevent this from happening ... but I don't think it's urgent.
You're right about still using 1.3.1. Apparently the Java update didn't remove old versions. What I don't understand is why cripple the Mac version by removing the OJI API because Windows no longer needs it. Apparently the new Mac plug-in has been "in the works" for over a year now.
Not blocking 1.9.2. The new Java plugin (yet to be released) will be the only supported Java plugin for Mac OS X in Firefox 3.6 and higher.
Flags: blocking1.9.2? → blocking1.9.2-
(In reply to comment #14) > Not blocking 1.9.2. The new Java plugin (yet to be released) will be the only > supported Java plugin for Mac OS X in Firefox 3.6 and higher. Can we get the summary to accurately reflect what's not blocking? "Java applet does not load on Mac OSX in FF 3.6 and 3.7" sounds like a blocker to me.
Flags: blocking1.9.2- → blocking1.9.2?
It wasn't blocking because there was nothing to do but wait for Apple at the time. The situation is different now - the plugin is there but not where we can access it. So *now* this bug is blocking because the problem is totally different. It is a matter of how we find the plugin to load it.
Flags: blocking1.9.2? → blocking1.9.2+
Also, the Java Plugin2 that's currently available in Apple's latest Java versions (on both 10.5.7/10.5.8 and 10.6) isn't yet (let's not mince words) release quality.
I think Apple would agree with my assessment. Once their port of Sun's Java Plugin2 *does* achieve release quality, I'm sure they'll find a way for users to "turn it on" (to make it easily available to any browser than can use it).
Someone really needs to tweak the summary here to reflect the real problem, since I assume *no* Gecko browser (not just Firefox) based on current trunk will load Java applets on any version of Mac OS X with a current JVM. (The lone exception discussed in comment 11 through comment 13 isn't worth the space in the summary.)
Hardware: x86 → All
Summary: Java applet does not load on Mac OS X in FF 3.6 and 3.7 → Java applet does not load on Mac OS X in Firefox 3.6 and 3.7
Summary: Java applet does not load on Mac OS X in Firefox 3.6 and 3.7 → Java applet does not load on Mac OS X in anything built on 1.9.2 branch and up
Summary: Java applet does not load on Mac OS X in anything built on 1.9.2 branch and up → Java applet does not load on Mac OS X in anything built on 1.9.2 branch and up (e.g FF 3.6 and up)
Josh, comment 18 makes the problem sound a lot worse than "figuring out how to find the plugin and turn it on." It sounds like we might not be aligned with Apple on when they're shipping a Java plugin that works with NPAPI.
I should point out that I won't consider Apple to have "released" their Java Plugin2 until they've done more work on it and they provide a GUI for end-users to "turn it on" (to make it available to all browsers that can use it).
> This leaves re-writing the JEP so that it doesn't use OJI. Or more precisely, re-writing the JEP to be an NPAPI plugin.
This sucks. We're planning on issuing Firefox 3.6 to users as a minor update from Firefox 3.5, thus breaking Java for all Mac users, if such a plug-in isn't ready in time. Based on that (and Steven's description above), I think we need to block 3.6 beta 1 on finding a solution to this problem. Is there a better place for that discussion? (In reply to comment #23) > Josh has ruled out restoring OJI on the trunk, and I basically agree > with him -- OJI hasn't been maintained for a long time, and there's > nobody both willing and able to maintain it. Yes, but it's been unmaintained for, as you say, a long time. Restoring it would put us back where we were with Firefox 3.5 and 3.0, which is at least having running and working Java on Mac OS X.
Priority: -- → P1
Interestingly, Mike Swingler (one of Apple's Java developers) has just posted to Apple's java-dev mailing list about Plugin2: http://lists.apple.com/archives/java-dev/2009/Sep/msg00074.html I assume the last part of the last sentence should read: > since the current state of the plugin is really [un]usable for > ordinary customers.
So the question becomes: When will "the next developer preview" appear on ADC, and when will it be released (via Software Update)? Here are links to download pages for all the Java updates Apple has so far issued for OS X 10.5 (I include them because Apple makes them quite hard to find -- particularly the older ones): http://www.apple.com/downloads/macosx/apple/application_updates/javaformacosx105update.html http://www.apple.com/downloads/macosx/apple/application_updates/javaformacosx105update2.html http://www.apple.com/downloads/macosx/apple/application_updates/javaformacosx105update3.html http://www.apple.com/downloads/macosx/apple/application_updates/javaformacosx105update4.html http://www.apple.com/downloads/macosx/apple/application_updates/javaformacosx105update5.html Here are the "post dates" (more or less the release dates) for these updates: Java for Mac OS X 10.5 Update 1 -- April 29. 2008 Java for Mac OS X 10.5 Update 2 -- September 24, 2008 Java for Mac OS X 10.5 Update 3 -- February 12, 2009 Java for Mac OS X 10.5 Update 4 -- June 15, 2009 Java for Mac OS X 10.5 Update 5 -- September 3, 2009 So new ones normally are released every 3-4 months, though Update 5 was released only 2.5 months after Update 4. Also, generally at least 2-3 "developer previews" appear on ADC before the actual release. Update 5 was faster -- it had only one developer preview. But it appears this update was just meant to catch Apple's JVMs up to Sun's latest version, and so was very straightforward. Update 5 was just released. And no developer preview for an "Update 6" has yet appeared on ADC. So I imagine we're 3-4 months away from "Update 6"'s release.
I assume Java updates for 10.6 will follow a similar pattern.
> http://www.apple.com/downloads/macosx/apple/application_update > /javaformacosx105update.html http://www.apple.com/downloads/macosx/apple/application_updates/javaformacosx105update1.html Sorry.
> So new ones normally are released every 3-4 months > So I imagine we're 3-4 months away from "Update 6"'s release. Actually, "4 months" would be more accurate. Of course this is only a rough estimate. It seems that quite a lot of work remains to be done on Apple's Java Plugin2, so more time may be needed.
As new developer previews start to become available on ADC, we'll get a better idea of how well Apple's work on Java Plugin2 is progressing -- and of whether a release might take longer than the standard 4 months of a "normal" release cycle.
I'll bite the bullet and make the following proposal: I think we should restore OJI and the JEP on the 1.9.2 branch (though not on the trunk and subsequent branches). As best we can tell, Apple's Java Plugin2 will be released no earlier than 4 months from now, and perhaps a month or two after that. That leaves us a gap of (perhaps) a few months between the first FF 3.6 release and that of Java Plugin2. I don't think it's acceptable to have Java unavailable to OS X users of Firefox during that gap. I also don't think the gap is long enough to justify my spending a month or more re-writing the JEP to no longer require OJI. Once Java Plugin2 is out and has been judged a successful replacement for the JEP, we can once more remove OJI and the JEP from the 1.9.2 branch. As the restoration of OJI on the 1.9.2 branch will (I suspect) be quite complex, there is the potential that it may introduce bugs. Because of this, OJI and the JEP should be restored (on the 1.9.2 branch) as soon as possible -- certainly before the first 3.6 beta release.
> I think we should restore OJI and the JEP on the 1.9.2 branch (though not on > the trunk and subsequent branches). It's also possible the patch for bug 442399 may need to be reversed on the 1.9.2 branch (perhaps only partially). But I won't be able to tell until OJI and the JEP are restored, and I'm able to run some tests (like those at http://poslfit.homeip.net/test/liveconnecttest.html).
Just an additional note: New installs with Mac OS X 10.6 who downloaded release Firefox first and after download Branch or Trunk cannot invoke the profile manager due to bug https://bugzilla.mozilla.org/show_bug.cgi?id=513747. As I need the stable release to access my bank account, I'm unable to test Branch and trunk until that bug is fixed...
Target Milestone: --- → mozilla1.9.2b1
This patch will allow Firefox to find the new Java plugin on 10.5 and 10.6. It works when the search path does not exist (10.4) and when there are multiple links to the same plugin. More comments on this coming soon, waiting on a little more information.
Assignee: nobody → joshmoz
In his post to the java-dev mailing list, Mike Swingler gives instructions for how to "turn on" Java Plugin2 "by hand" (by playing with soft links), on both OS X 10.5.8 and OS X 10.6. http://lists.apple.com/archives/java-dev/2009/Sep/msg00074.html But they're a little hard to follow, so I'll spell them out more clearly: Turning On Java Plugin2 1) Remove the JavaPluginCocoa.bundle link in /Library/Internet Plug-Ins: a) cd "/Library/Internet Plug-Ins" b) sudo rm JavaPluginCocoa.bundle 2) Create a soft link to Java Plugin2 (single command broken onto two lines because of length): sudo ln -s /System/Library/Frameworks/JavaVM.framework/Resources/JavaPlugin2.plugin Turning Off Java Plugin2 1) Remove the JavaPlugin2.plugin link in /Library/Internet Plug-Ins: a) cd "/Library/Internet Plug-Ins" b) sudo rm JavaPlugin2.plugin 2) Create a soft link to JavaPluginCocoa.bundle (single command broken onto two lines because of length): sudo ln -s /System/Library/Frameworks/JavaVM.framework/Resources/JavaPluginCocoa.bundle
We should not restore the JEP in Gecko 1.9.2. Doing so would be a big job, it would reverse a lot of gains, the potential for serious regressions is massive, and the benefits just don't justify it. We can't simply check the necessary components back in again - we entirely removed their support systems and then made numerous major changes to related plugin, DOM, layout, and JS code (for good reasons). Without a doubt, the JEP is a better Java plugin than JavaPlugin2 at this point. This fact is not ideal. However, JavaPlugin2 is functional today, it will work for many users, and we have good reason to believe that Apple will be improving it rapidly. From the Apple java-dev post Steven quoted above: "We will likely add a user interface to swizzle this symlink in Java Preferences in the next developer preview." This clearly indicates that Apple expects to deliver a much-improved JavaPlugin2 in the next Java update. If we enable the use of JavaPlugin2 in Firefox 3.6, the hit that Java takes on Mac OS X amounts to the quality delta between JavaPlugin2 and JEP, which will probably only be meaningfully negative for a few months from now. Java remains an important component for some users, but it is not so critical that we can't deal with this quality delta for a bit. This is a small price to pay for what we were able to accomplish.
Attachment #399122 - Flags: review?(smichaud) → review+
Comment on attachment 399122 [details] [diff] [review] fix v1.0 This *doesn't* fix this bug, or the underlying problem (making a usable Java plugin available to FF 3.6 and up, or to other Mozilla Corp programs on the trunk and the 1.9.2 branch). But (though I haven't tested it) it does look like a serviceable way to allow us to find and load Apple's Java Plugin2.
pushed to mozilla-central http://hg.mozilla.org/mozilla-central/rev/b3064f431c65 Leaving this bug open until final resolution for 1.9.2 branch.
Preliminary results testing Java Plugin2 (with today's Minefield and Namoroka nightlies) on OS X 10.6: 1) Sun's Clock example plugin (http://java.sun.com/applets/jdk/1.4/demo/applets/Clock/example1.html) This applet does load, and at first sight appears to work normally. But scroll the page down until the top of the applet is even with the bottom of the Bookmarks Toolbar. Notice how the clock overwrites the tab bar. Keep scrolling the page down until the clock would normally be zero-clipped (and completely invisible). Notice that it (or part of it) displays over the navigation toolbar, the title bar, and even outside of the browser window. Open another tab and notice that the clock applet stays visible. 2) Sun's ArcTest example plugin (http://java.sun.com/applets/jdk/1.4/demo/applets/ArcTest/example1.html) Once again the applet appears to function normally when first loaded. But open a new tab, and you'll see that the bottom part of the applet (with the Fill and Draw buttons) leaks into the new tab. Furthermore these buttons still work in the "other" tab: Press the Fill button and switch back to the first tab (where ArcTest is loaded) -- notice that its display has changed. 3) NOAA weather applet (e.g. http://radar.weather.gov/radar.php?rid=twx&product=N0R&overlay=11101111&loop=yes) Wait until the applet finishes loading and starts to loop. Scroll the page up and down, and notice terrible flickering and artifacts outside of its clipping rect (and even sometimes outside the browser window). Open a new tab and notice that part of the applet "leaks" into it. Click on the "leaked" part and notice that the view gets zoomed out. Right-click on it and notice that the view gets zoomed in. 4) Jigzone applet (this bug's URL) Same problems as described above, and a very annoying additional problem: Open two tabs and then open this bug's URL in the third tab. Scroll the page down so that the applet completely obscures the part of the tab bar containing "its" tab (the third tab in the tab bar). Click on the first tab to give it focus. The applet will (of course) leak into the first tab. But, because it obscures "its" tab (the third tab in the tab bar), it won't be possible to switch back to the third tab to get rid of the applet -- unless you first close one of the other tabs.
(Following up comment #41) These examples weren't the least bit hard to find. In fact it's more of a challenge to find Java applets that *don't* have very serious problems in Apple's current Java Plugin2. There were also a bunch of focus problems that I didn't even feel it necessary to mention -- beside the other problems, the focus problems pale into insignificance. Similar problems used to happen in the Safari 4 distros that came with earlier SnowLeopard seeds (e.g. 10A354) -- until Apple changed Safari to never use Java Plugin2. (You used to be able to use Java Plugin2 in Safari after you'd done Get Info on the Safari app bundle and chosen to "open it in 32-bit mode".) These problems won't get better soon. If we're lucky (and Apple is lucky), things will start getting better toward the end of their release cycle for the next Java Update. But by any reasonable estimate that's months away. And until Apple actually releases the new Java Update, only developer builds will be available, on Apple's Apple Developer Connection. The Java developer builds should be available without cost (to those who have a free ADC account). But they will be clearly marked use-at-your-own-risk (at they should be), and (as with Apple's other Java updates) it won't be possible to uninstall them.
Requesting approval for 1.9.2. This Java plugin is better than nothing until we get the improved plugin, probably some time around January 2010, but maybe as early as December or as late as February. That is the best ETA we have right now.
At bug 517355 I've posted a preliminary patch that restores OJI, Liveconnect and the JEP on the 1.9.2 branch. I have no objections to this bug's patch landing on the 1.9.2 branch -- it shouldn't be too hard to make the two patches get along.
Just for reference (regarding comment 6 and comment 10): it was really bug 485984 that removed OJI from the tree.
1.9.2 and 1.9.3 are really different situations, a bug covering both doesn't make sense any more. I'm going to make this bug as fixed because of the patch that resolves 1.9.3 and leave bug 517355 to cover 1.9.2.
Summary: Java applet does not load on Mac OS X in anything built on 1.9.2 branch and up (e.g FF 3.6 and up) → Java applet does not load on Mac OS X in anything built on 1.9.3 branch and up
Target Milestone: mozilla1.9.2b1 → mozilla1.9.3a1
Summary: Java applet does not load on Mac OS X in anything built on 1.9.3 branch and up → Java applet does not load on Mac OS X in anything built on 1.9.3
So we can close this bug now?
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.