Closed Bug 303161 Opened 19 years ago Closed 19 years ago

include Java Embedding Plugin (JEP) with Firefox

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: jaas, Assigned: mark)

References

(
URL
)

Details

(Keywords: fixed1.8)

Attachments

(1 file, 1 obsolete file)

Patch
1.12 KB, patch
jaas
: review+
asa
: approval1.8b4+
Details | Diff | Splinter Review 
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.
Flags: blocking1.8b4?
Attached patch Patch, untested (obsolete) — — Splinter Review 
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.
Attachment #191428 - Attachment is obsolete: true
Attachment #191428 - Flags: review?(joshmoz) → review-
Attached patch Patch — — Splinter Review 
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+
Attachment #191443 - Flags: review+
> 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.
Keywords: fixed1.8
Fixed on trunk.
Assignee: joshmoz → mark
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Blocks: 305098
Depends on: 313807
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: