We should probably include the Java Embedding Plugin (JEP) with Firefox on the Mac, as it fixes lots of our Java problems. With it, Java on Mac Firefox actually works, and pretty well. We already include JEP with Camino. We really don't have another option for fixing Java on the Mac without supporting Apple's new plugin architecture. There is a binary of the plugin in the tree already. It adds 300-400k to our download size (that is the approximate compressed size of the plugin). For those of you who don't know, we can't use Apple's latest Java plugin. We are stuck with an old version that they don't maintain any more, but still ship for people like us. Is is really buggy when Firefox uses it. JEP is basically a wrapper around their new plugin that allows us to use it.
If we're going to do this, which I think we should, we should do this for 1.5 beta.
Created attachment 191428 [details] [diff] [review] Patch, untested Enable JEP on the Mac for Firefox.
Attachment #191428 - Flags: review?(joshmoz)
Comment on attachment 191428 [details] [diff] [review] Patch, untested We should really have it as a build option and put it in the default configs of ff/camino
I don't think it should be a build option. It is just a file copy, and it is only for Macs. It just isn't a very useful option to have, and thus not worth the option. Mark agrees.
Created attachment 191443 [details] [diff] [review] Patch The browser target depends on the plugin target, the plugin must come earlier.
Attachment #191443 - Flags: review?
Attachment #191443 - Flags: review? → review?(joshmoz)
The second patch seems to work, but JEP doesn't seem to work well in FF any more. Very odd. Steven - does JEP 0.9.3 work well with a recent FF nightly build for you?
I've done quite a bit of testing of the 2005-07-31-07-trunk Deer Park nightly in connection with bug 302843. And just now I briefly tested 2005-08-02-trunk (the most recent currently available) with http://www.java.com/en/download/help/testvm.xml and the http://weather.gov/ looping applets. I didn't notice any Java-specific problems (or at least problems that I thought were Java-specific). What have you been seeing? (Visit the www.java.com site to be sure that you haven't accidentally fallen back to Java 1.3.1.)
> 2005-08-02-trunk Typo -- should have been 2005-08-02-07-trunk. And I tested on 10.2.8, 10.3.9 and 10.4.2 (with Java 1.5).
(Using current builds:) When JEP does work in Firefox, most applets are much slower than in Camino or in a non-JEP Firefox. Try some of the sample applets at http://mrl.nyu.edu/~perlin/ . Those that do load barely perform. Perhaps this has something to do with the event handling changes that Firefox recently "inherited" from Camino? Maybe it's got something to do with running applets in tabs?
I just tried a couple that looked like they might be particularly CPU intensive, in Firefox 1.0.6 and the 2005-08-02-07 Deer Park nightly. The tests were done on Mac OS X 10.3.9. Yes, the applets took much longer to download (or seemed to take much longer) using the Deer Park nightly, even when they were already in the JVM's applet cache (I'll need to look into that). But once they were loaded (into different tabs on the same page), I noticed no speed differences whatsoever ... at least at first. Then I tried adding four more tabs to each page, each with a weather.gov applet running at full speed. This (of course) caused the Perlin applets to run more slowly in both browsers, but I noticed a larger fall-off in the Deer Park nightly. If I had to guess, I'd blame this on the greatly increased number of spurious updates between Firefox 1.0.6 and the Deer Park alphas and nightlies. In both applets that I tested, you drag the mouse around to make them "go" -- in Deer Park this results in a real storm of spurious updates. The applets I played with were the fourth and the sixth from the left in the top row. Please try these. Also let me know which ones you tested, or found particularly troublesome. I'd also like to see examples of speed problems (if you can find any) that _don't_ involve dragging the mouse.
Steven, the top-left applet never even gets off the ground in Firefox. Seems to be a frames problem, it's better (though still is slow to start) when it's not run in a frame. Performance doesn't seem as problematic where the mouse isn't a factor. I'm also noticing problems with the scroll wheel dying and, to a lesser extent, keyboard input not being recognized, when a window had been used to host an applet.
> I'd also like to see examples of speed problems (if you can find any) that > _don't_ involve dragging the mouse. I've found an applet that tests raw speed (of the Java GUI) without (for the most part) any mouse input -- http://segal.org/java/CanvasTable3/index.html. With it the speed differences between Firefox 1.0.6 and the 2005-08-02-07-trunk Deer Park nightly are minimal. I'm also happy to say that, with this applet, the JEP/Mozilla-family-browser combination is almost twice as fast as Safari :-)
> the top-left applet never even gets off the ground in Firefox. I didn't have any problems with it. I'm now not even seeing a longer load time in the Deer Park nightly. > I'm also noticing problems with the scroll wheel dying and, to a lesser > extent, keyboard input not being recognized, when a window had been used to > host an applet. I assume these problems happen with recent Deer Park builds, and not with Firefox 1.0.6. If they _do_ happen with Firefox 1.0.6, then maybe it's time to start filing bugs at my SourceForge bugs Tracker :-( (Of course you'd need to be able to describe the problems precisely and give examples.) (By the way, the scroll wheel won't (or isn't supposed to) have effect on an applet unless the mouse is over that applet. If you have multiple applets in the same page, you also need to have (previously) clicked the mouse on the applet to make it active.) Even if these problems (and others that people may have encountered) happen only in Deer Park, it may be necessary to address them (or some of them) before the Java Embedding Plugin is included with Deer Park. And if I'm right about the contribution to these problems of Deer Park's spurious updates, considerable changes may be required to Deer Park.
It is worth noting that Java performance without JEP on FF isn't that bad - certainly much better than with JEP. Odd, but in any case, not shipping with JEP is not the end of the world. We'll be getting lots of new drawing code soon, so we can work on using JEP or some other solution on the 1.9 trunk soon.
I haven't seen any consistent performance differences. You guys really do need to give me some convincing and reproduceable demonstrations of them. The same goes for other problems. You ask nothing less of your own users. That said, Java 1.3.1 _is_ faster, I think (on the Mac platform at least) than Java 1.4.X or Java 1.5. Did anybody try the applet I mentioned in comment 12?
not a blocker but we;d take this if it lands before beta.
Flags: blocking1.8b4? → blocking1.8b4-
Comment on attachment 191443 [details] [diff] [review] Patch Removing review request until JEP and DeerPark can play nicely together.
Attachment #191443 - Flags: review?(joshmoz)
I updated my nightly of Deer Park significantly, and reinstalled JEP, and everything works fine now. JEP definitely helps with applets in a huge way.
Comment on attachment 191443 [details] [diff] [review] Patch We're in a tight spot because the old Java plugin has serious security flaws and will probably have to be disabled. The result of that is that we'll have no Java on Mac. Our plan is to try to test out the JEP with Firefox and if we can get it working to a satisfactory level, ship that in 1.5. If we cannot get it working, we'll probably not support Java on Mac in 1.5.
Attachment #191443 - Flags: approval1.8b4+
> If we cannot get it working, we'll probably not support Java on Mac in 1.5. Better (if the JEP can't be included) to turn Java off by default, and let users re-enable it. Otherwise you'll probably have a large-scale rebellion -- many users will stick with Firefox 1.0.X. By the way, what are the Java 1.3.1 security issues that you're worried about? And are they general issues that even Sun has never addressed, or are they specific to the Mac? If they _are_ specific to the Mac, it may be worth your while to apply pressure to Apple. They _have_ been upgrading Java 1.3.1 on Tiger. And, though they don't acknowledge any security fixes, I strongly suspect that their main reason for doing so is to include Sun's latest Java 1.3.1 security fixes. If they can fix Java 1.3.1 on Tiger, they can also do it on Panther. Though I'll admit that trying to get them to do it on Jaguar is a probably a stretch too far.
Checked in to 1.8 branch. Trunk is closed, leaving open until this is checked in there too.
Fixed on trunk.
Assignee: joshmoz → mark
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.