Closed Bug 197813 (osxjava1.4) Opened 20 years ago Closed 18 years ago

Support Java 1.4.x/1.5.x applets, JavaPluginCocoa.bundle

Categories

(Core Graveyard :: Java: OJI, enhancement)

Product:
Core Graveyard
Component:
Java: OJI
Platform:
PowerPC
macOS
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.8beta4

People

(Reporter: pev, Assigned: smichaud)

References

(
URL
)

Details

(Keywords: relnote, Whiteboard: plugin solution: http://javaplugin.sourceforge.net/)

Attachments

(3 files, 1 obsolete file)

This is a screenshot of the Java test page
15.47 KB, application/pdf
Details
GDB output on NSBeep
17.14 KB, text/plain
Details
Processes running
7.64 KB, text/plain
Details 
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705)
Build Identifier: 

Apple has released Java 1.4.1 on Mac OS X (from version 10.2.3 and up).
However, currently the only browser that supports Java 1.4.1 for applets is
Apple's own Safari:

http://developer.apple.com/techpubs/macosx/ReleaseNotes/java141/multiplevms/
index.html

Please consider supporting Java 1.4.1 as soon as possible. It would be best
if this was made dynamically configurable in the <applet> tag or in a
similar way.


Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Note that bug 197453 reports that there might be a problem with Java in the
latest builds - possibly related to the 1.4.1 upgrade (not yet confirmed). It
was supposed to be transparant ...
MacOS->beard@netscape.com
Assignee: joshua.xia → beard
Apple implementation for Java will install BOTH Java 1.3.1 and 1.4.1. Their own
browser, Safari, already supports Java 1.4.1.

Internet Explorer and Mozilla will use 1.3.1.

To see your Java version, use the URL
http://java.sun.com/docs/books/tutorial/applet/practical/properties.html. The
Mac OS X Java 1.4.1 release notes has a lot of useful information on this
1.3.1/1.4.1 combo.

Mac OS Java Plug-in needs to be rewriten to use Java 1.4.1.

However, I'm no programmer.

I can confirm that Mozilla 2003031708 uses only Java 1.3.1 and that applets are
running very well.

This is not a bug, but Java 1.4.1 support would be a great enhancement on the
Mac OS X platform.

Regards,

- Jacques
I am developer who has had problems with JRE 1.3.1 on the MAC platform. The
problems are not related to Mozilla rather issues with the JVM. As far as I know
this JVM will no longer be supported.

The new JRE fixes the issues we were having with 1.3.1 but this JRE is only
available under Safari. Although this might be fine it would be great if we
could say to our clients that you can use Safari if you want but either of
Camino or Mozilla is also freely available and they both are browsers that we
support.

Hence, JRE 1.4.1 support on a MAC would be good to have.
URL: http://developer.apple.com/cgi-bin/se...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Support Java 1.4.1 applets → Support Java 1.4.1 applets, JavaPluginCocoa.bundle
Flags: blocking1.4b+
unless you are a Mozilla driver, you are not authorized to set blocking (+)
flags.  you can request them (?)
Flags: blocking1.4b+
Sorry... I guess that is a bad UI (it was confusing)... anyway it is requested.
Flags: blocking1.4b?
Flags: blocking1.4b? → blocking1.4b-
For an applet, we need JRE 1.4 support in Mozilla:

Safari current release is a beta: the applet support has some problems.

It would be nice if Mozilla could use the last JRE 1.4 provided by MacOs
Java 1.3.1 applet does not work well with Mozilla or Navigator 7.02.  This can
be demonstrated by going to games.yahoo.com/games and selecting Mahjong
Solitaire.  The window comes up cropped on the bottem and does not expand. 
Also, Java 1.3.1 hangs when trying to reenter Power ProSearch at
pro.university.investools.com.  The sock order entry window at
webbroker.tdwatershouse.com needs one or more reload attempts to fully comeup
under Java 1.3.1.  None of these problems occur using Safari.  I suggest all
browsers upgrade to Java 1.4.1.
Java 1.3.1 applet does not work well with Mozilla or Navigator 7.02.  This can
be demonstrated by going to games.yahoo.com/games and selecting Mahjong
Solitaire.  The window comes up cropped on the bottem and does not expand. 
Also, Java 1.3.1 hangs when trying to reenter Power ProSearch at
pro.university.investools.com.  The sock order entry window at
webbroker.tdwatershouse.com needs one or more reload attempts to fully comeup
under Java 1.3.1.  None of these problems occur using Safari.  I suggest all
browsers upgrade to Java 1.4.1.
Is there *anyone* working on this?  The bug has been around for greater than 2
months now.  

I want to do whatever I can to expedite this issue including fixing it myself or
starting a thread about fixing this to produce as much info about 1.4.1 support
in Mozilla as possible.

If anyone has done work on this please let me know.  I don't want to duplicate
anything.
Kevin - have you worked on this at all?  My guess is, if you haven't touched it, no one else has.

bug 185000 dealt with Java integration for Unix platforms, and seems like it might apply, since 
Camino (or at least Moz for OS X) seems to use the code they touched.

Unfortunately, the work in that bug defines Unix = Solaris (sparc) -or- i386 Linux.  It might be a 
place to start.  Or not.  
I haven't had a chance to fix this yet.  It is a huge priority on my list it is
just that right I have other fires to put out :)

Java on OSX is essentially totally broken and useless. My thinking is we just
ported 1.4.1 over to OSX then this would resolve a LOT of bugs.  

Wi
I'd LOVE to see a straight port of Sun's Java to OS X -- not only would it fix
Mozilla's problems using Java on OS X, but it might motivate Apple to be a
little more honest (i.e. humble) in its Java hype.

I wonder whether a KHTML <-> OJI translator (a plugin of some sort) might also
fit the bill.  (See
http://developer.apple.com/darwin/projects/webcore/index.html.)  But I notice
that Apple is telling people to hold off any "WebCore" development until the API
is firmed up.  And in any case I don't know enough about "WebCore" to know
whether it provides the needed functionality.


Java has ALREADY been ported to OSX by Apple it is just that Mozilla can't use
it... still links to the old plugin.
Yes, but Apple didn't do a _straight_ port.  Among other things, they didn't
port the OJI plugin (called NPOJI6XX.dll on Windows and libjavaplugin_oji.so on
Solaris).  If they had, Mozilla would have no trouble using Java 1.4.1 on OS X.

Furthermore, Apple has changed its Java-applet programming model twice in the
recent past.

Prior to 10.1 you had to use the "Java Embedding Framework" -- which was fine
for Mozilla, because it could use its MRJCarbon plugin, which is in effect a
Java-Embedding <-> OJI translator.

As of 10.2, the Java Embedding Framework is still available.  But when 10.2
first came out you were encouraged to use the "Java Applet.plugin" -- which is a
Netscape-4.0-style plugin, and so is still fine for Mozilla.

(http://developer.apple.com/documentation/ReleaseNotes/Java/Java131MOSX10.2RN/applets/chapter_2_section_1.html)

With the release of Apple's version of Sun's Java 1.4.1, the applet programming
model has changed yet again.  Now you have to use the "JavaPluginCocoa.bundle",
as Safari does.  But (as far as I can tell) Apple hasn't bothered to document
the JavaPluginCocoa.bundle, so that other browsers could be changed to support
it too.

(Mozilla can still use the MRJCarbon plugin or the "Java Applet.plugin", but
these only give you Java functionality at the 1.3.1 level.)

My guess is that the key to the JavaPluginCocoa.bundle lies in KHTML and Apple's
"WebCore".  But it might very well be easier to port Sun's OJI plugin to OS X. 
If so, why not do that instead?


If the key to using Java 1.4.1 for plugins is in WebCore OmniWeb haven't found
it. I checked my OmniWeb 4.5 install and it is still using the old Java 1.3.1
plugin, just like Mozilla, despite OmniWeb 4.5 now using Apple's WebCore framework.

It seems only Safari can access Java 1.4.1 for some reason... Maybe it's just a
WebCore documentation issue or maybe Safari goes beyond current WebCore to
access JavaPluginCocoa.bundle? 

If Apple won't give outsiders access to JavaPluginCocoa.bundle either directly
or via WebCore then I guess porting Sun's OJI plugin to OS X is the only option
available? 

Whatever the situation this needs to be resolved asap as Java 1.3.1 won't cut it
anymore. (E.g. Does OS X 10.3/Panther still include the Java 1.3.1 runtime? That
could be nasty...)

This is not meant to be a bug report on Safari but is offered to hopefully
expand what is increasingly becoming a burning issue for us.

Even using Safari (MAC's supposed supported browser) with our Java Applet we obtain:
"java.lang.ClassFormatError: DACApplet (Bad magic number)".
There is nothing wrong with the code since it runs fine under windows and even
under a Mac if we user the applet launcher directly.
There are issues with Safari too, this further raises the priority of Mozilla's
Java 1.4.1 support for Mac.
IE seems to use 1.4.1, through it's own Java VM, but it doesn't support
"LiveConnect" which has been implemented in Netscape (and assumably in Mozilla)
for some time.
I've tested the system under OSX 10.2.6 with the latest update of Mac Java and 	
Mozilla 1.5b
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030827.

PLEASE HELP!
We are doing this for broad use within Education and this could see wide
acceptance of Mozilla
Since I applied Apple's Java 1.4.1 Update 1, Mozilla 1.5b the java plugin is no
longer available.  Is there a setting to fix so that Mozilla can still use the
1.3.1 plugin?
Having done a quick class dump on the Mach-O "executable" inside the bundle, I
can confirm that its api is very simple. It vends an NSView which is simply
composted into the page as an NSView. This conforms to a protocol that allows
the plugin to be started, stopped, initialized, and destroyed. I highly
reccomend that you take a look at the code in the bundle, which is at:

"/Library/Internet Plug-Ins/JavaPluginCocoa.bundle/Contents/MacOS/JavaPluginCocoa"

On my system. Use the application class dump,
http://homepage.mac.com/nygard/Projects/, which I installed via Fink. It gave me
the interfaces for the classes in the bundle, of which EmbeddedAppletView is the
only non-trivial one. Looks like it should be a snap. Bundles can be loaded by
location by using methods in Foundation Kit's NSBundle.

As willing as I am to try to integrate this, my knowledge is with Cocoa, I would
be lost trying to do this from within the Firebird codebase. I can help to probe
the API for this bundle.
I'm a nobody but I'd like to be able to play the Yahoo games (popcap) with
Mozilla.  Java should be automatically loaded, so why isn't it showing up in
"Help-->About Plug-ins"? I quickly toured through Preferences and found
Javascript but not Java.  What am I missing?  

And will I need to upgrade to Jaguar before putting in Java 1.4.1? According to
this bug, that wouldn't help anyway.

The popcap and lunchbreakgames just sit there, but another Java game gave me an
error saying that Java wan't enabled.

I have Mac Sys 10.1.5, Mozilla 2003111303 

///Polly
Polly, what you're actually experiencing is Bug 97613. Read through the
comments, and look for my work-around to get java working with Mozilla and Mac
OSX 10.1.5, somewhere around Comment 22 I believe.
As another commenter said above, I'm a nobody too. I've been tracking this bug
for some time and no solution ever seems to be forthcoming. Could one of the
developers please see to it that comments are added to the release notes why
Mozilla continues not to be able to use the latest JVM - and when this is
expected to be rectified? It's going on almost a year since Apple released JVM
1.4.1 for Mac OS X, and I'm getting awfully tired of having to use Safari for
Java sites that won't work with an earlier version.
There doesn't seem to be any coordination on this bug. Lots of ideas and people
willing to help, but no steering. Before anything else happens, we should
coordinate. (FWIW, I too have seen this bug and have voted for it.) The next
question is who coordinates and which directions should we pursue? Let's make a
short list and get working. 



Just so that people know ...

I have no relation to Mozilla, but I've been working on reverse engineering
JavaPluginCocoa, and have made some progress.  I hope to have something usable
(at the alpha or early beta state) available in a couple of weeks.  My current
intention is to put it up on SourceForge.


What are you reverse engineering?  The interface?   A hello world app?
documentation?
I'm learning how to use JavaPluginCocoa's "API", as revealed by "class-dump".

If things go as planned, I'll write another Cocoa bundle (called possibly
"JavaPluginCarbon" or "JavaEmbeddingPlugin"), that uses JavaPluginCocoa's "Cocoa
API" internally, but exports another C/C++ API for use by a Carbon application
-- such as Mozilla's MRJCarbon plugin.  This "JavaPluginCarbon" (or whatever I
call it) will be modelled after the Cocoa part of Apple's CocoaInCarbon sample
(http://developer.apple.com/samplecode/Sample_Code/Cocoa/CocoaInCarbon.htm),
which is used as an example in Apple's "Integrating Carbon and Cocoa in your
Application"
(http://developer.apple.com/documentation/Cocoa/Conceptual/CarbonCocoaDoc/index.html).

As you may have guessed, the "Carbon API" will resemble Apple's old "Java
Embedding API" (which is what the MRJCarbon plugin currently uses).  I'll also
provide a patch to the MRJCarbon plugin to make it use this "Carbon API".

Much thanks, by the way, to Matthew Cox and Bill McGonigle, for their messages
of 10-19 and 10-22 (respectively).  Without these leads I wouldn't have been
able to find my way.

I didn't intend to say anything before I released my source code, and I'm sorry
that many of your questions will have to be left in suspense until I do so.  But
I felt I had to say something after reading the most recent messages from Brian
Dantes and Martyr.


While Steven's work sounds promising, I would feel a lot better if the person to
whom this bug is assigned, Patrick Beard, or any other actual MacOS X Mozilla
developer would comment. Since this bug was opened almost nine months ago, it
has become almost like a thread in a forum. I still would really like to see
this at least show up in the known issues section of the release notes for the
Mac version.
I agree with Brian. This should be in the known issues at the very least. It's a
few lines of doc! (I could write it in my sleep.) The bug should also be
reassigned to the person doing the work. However, I don't have to power to do
either one of these things. I wish we could still vote multiple times for a
single bug -- I'd use all my spare votes on this one.


Furthe observations:

I moved both 'Java Applet.plugin' and 'Java Applet Plugin Enabler' out of the
'Internet plug-ins' folder and then restarted both Mozilla 1.6a and Safari. I
then tried out the Java version of Yahoo messenger at

    http://messenger.yahoo.com/ 

Worked fine with Safari, but with Mozilla I get a missing plug-in symbol.
Looking at the plug-ins that both browsers have loaded, only Safari has the a
Java plug-in listed:

  Java Plug-in for Cocoa
    Java 1.4.1 Plug-in ( Cocoa ) — from file “JavaPluginCocoa.bundle” 

This leads me to believe that either it is because the plug-in is written in
Cocoa, that is causing the issue, or because there was a subtle change in the
plug-in spec. Is there a standard system call to get plug-ins, that Mozilla
makes use of, or do you assume the location of the plug-ins folder?
*** Bug 228938 has been marked as a duplicate of this bug. ***
Well, it's been three weeks instead of two, and I'm still not finished
with my "Java Embedding Plugin" :-(  But I'm closer than I was, and I
haven't given up :-)

It's been a long, hard slog -- with most of my time spent finding
workarounds for bugs in JavaPluginCocoa and (particularly) in the
Cocoa-Carbon interface (what Apple describes in their "Integrating
Carbon and Cocoa in Your Application" document).  But my Java
Embedding Plugin now has basically all the functionality of Apple's
old Java Embedding API (clipping isn't quite done yet, but it
shouldn't take much longer).

I'm going to take a couple weeks' break for Christmas, but then I'll
get back to work.  My current best estimate is that I'll have
something to show for my work in January (possibly late January).


*** Bug 230181 has been marked as a duplicate of this bug. ***
*** Bug 230341 has been marked as a duplicate of this bug. ***
How's the work going, Steven? Curious Mac users want to know. :) 

(In reply to comment #32)
> I'm going to take a couple weeks' break for Christmas, but then I'll
> get back to work.  My current best estimate is that I'll have
> something to show for my work in January (possibly late January).
> 
> 


Apple just released Java 1.4.2 et Safari 1.2. They say that Live Connect should
work by now. Perhaps it is good news for us too ?
MacOS X.3.2, Java 1.4.2, Mozilla 1.6

Java applet requiring Java 1.4.0 or better still not happy.
Continues to work fine under Safari.
Steven, in no way to I mean to be disparaging all the hard work you've done, but
are you sure you're on the right track?

Apple's Embedding API is described by them as being end-of-life & considerably
less functional than using the Java Plugin API from Sun. Much of the Plugin's
functionality isn't supported if you're using it.

Let me see if I understand what you've build here:

* JavaPluginCocoa.bundle -> gives a Cocoa NSView
* Cocoa in Carbon -> embed a Cocoa NSView in a Carbon window (for gecko)
* Your Embedding Code -> emulates Apple's old deprecated Java Embedding API
* This hooks into Mozilla as the previous plugins did

Is that right?

That's really impressive work.

You're right. Apple *really* aren't documenting how to embed 1.4. There's not
even really much about how to do 1.3. But the impression I get from the
fragments they do say is its supposed to be easier than what you've gone through.

There are a bunch of things I don't understand:

* all of the Apple documentation claims Mozilla & Camino are using the Java
Applet.plugin, whears IE uses the old Java Embedding Framework

* however the Mozilla view of things seems to be that we use the Embedding
Framework. They can't both be right.

* Apple have never explained why using Java Applet.plugin leaves you stuck at
Java 1.3. JavaPluginCocoa.bundle is all well and good, but not every application
is Cocoa - Mozilla is Carbon, so why isn't there a Carbon interface to 1.4?

* What Apple say is that the 1.3 & 1.4 JVMs expose the same functionality at the
Java Plugin product Sun ships for Windows, Solaris & Linux - doesn't this imply
that there's a relatively simple way to leverage the way the Mozilla Unix &
Windows code embeds Java to embed Java on OS X?

* It seems this would be easier than the layers of cruft around Mozilla's oji
implementation. Some of the code you've been working with dates back to Mac OS 8
or 9 and JDK 1.1.8. I don't envy you!

Sorry. Too many questions and not enough answers. I'm curious what you've
discovered.
Just got some feedback on this. It seems JavaPluginCocoa.bundle is not in any
way intended to be a browser plugin. The only supported way to embed the 1.4 VM
is to use WebKit, which is obviously not an option for us (or Opera, Microsoft etc).

I hope this is a temporary problem, that will be addressed now the team at Apple
got 1.4.2 out of the door. The problem with using an unsupported API like
JavaPluginCocoa.bundle is its almost gauranteed to break when 10.4 comes out, or
indeed it might potentially break after any OS or Safari update :(
Sorry to take so long to respond.  At first I wanted to wait until I had
something more positive (or negative) to say :-)

Progress is slow.  I have something, but it's not ready for release.  I'm not
sure it's possible to do any better, but I intend to keep trying for at least
another couple of weeks.

(In reply to comment 35)
> How's the work going, Steven? Curious Mac users want to know. :) 
(In reply to comment 38)

> Let me see if I understand what you've build here:
> 
> * JavaPluginCocoa.bundle -> gives a Cocoa NSView
> * Cocoa in Carbon -> embed a Cocoa NSView in a Carbon window (for gecko)
> * Your Embedding Code -> emulates Apple's old deprecated Java Embedding API
> * This hooks into Mozilla as the previous plugins did
> 
> Is that right?

Yes.

> * all of the Apple documentation claims Mozilla & Camino are using the Java
> Applet.plugin, whears IE uses the old Java Embedding Framework

I don't know about IE (or Camino), but Mozilla does use the Java Applet.plugin
(though it prefers the MRJCarbon plugin if it's present).  However, the Java
Applet.plugin uses the Java Embedding framework :-)  That's why it's limited
to Java 1.3.1.

> * What Apple say is that the 1.3 & 1.4 JVMs expose the same functionality as
> the Java Plugin product Sun ships for Windows, Solaris & Linux ...

That's false.  There's no functionality equivalent to the "OJI plugin" (see
comment 15).

(In reply to comment 39)

> The only supported way to embed the 1.4 VM is to use WebKit, which is
> obviously not an option for us (or Opera, Microsoft etc).

Exactly :-)  As far as I can tell, other browers would have to be substantially
rewritten to work like Safari (and use the high-level WebKit APIs).  There's
no reason they should have to ... and in any case I doubt it will happen.


just a Query: Is this bug/enhancement going to be resolved as "won't fix" as it
is not possible to fix? I hope not.

Has anyone looked seriously into the possiblity of porting the Sun OJI plugin to
be used by Mozilla? Is a port of the OJI plugin even possible.
I am interested too. I have an app here that uses a signed applet + signed html
(jar protocol, which Safari AFAIK doesn't support).
(From comment 42)

> Has anyone looked seriously into the possiblity of porting the Sun
> OJI plugin to be used by Mozilla? Is a port of the OJI plugin even
> possible.

I haven't done so ... though I was the one who suggested it.  The
problem (which I didn't realize at the time) is that the Sun license
for their "Community Source" distribution
(http://wwws.sun.com/software/communitysource/j2se/java2/index.html,
which includes source for the OJI plugin) is _very_ restrictive.  To
quote from Sun's summary of the license:

  Modified source code cannot be distributed without the express
  written permission of Sun Microsystems, Inc.

  Binary programs built using modified Java 2 SDK source code may not
  be distributed, internally or externally, without meeting the
  compatibility and other requirements described in the License
  Agreement.

Compatibility testing using something called the "Technology
Compatibility Kit" seems to be required, which involves paying Sun a
(probably substantial) "annual fee".  If I'm reading the actual
license correctly (and of course IANAL), these requirements don't
apply if your modifications are "for research use" ... but that seems
to be limited to academic research and teaching, which doesn't seem to
be what's involved here :-)

Eric Raymond and IBM have recently been trying to persuade Sun to
open-source Java, and Sun's at least agreed to talk to IBM ... but who
knows how long that process will take, or whether it will lead
anywhere.

Finally, even if there weren't any licensing problems, whoever ported
the OJI plugin would still have to deal with a lot of the technical
problems I've been struggling with.  There are two main reasons for
this:

First, Apple's Java 1.4.X implementations are Cocoa-based at their
very core.  You can see this by doing a class-dump on
/System/Library/Frameworks/JavaVM.framework/Libraries/libawt.jnilib.
Which means that whoever wants to support non-Cocoa browsers (all of
them but Safari, as far as I know) will need to use Apple's
Cocoa-Carbon interface, as described in their "Integrating Carbon and
Cocoa in Your Application" document.

Second, this Cocoa-Carbon interface is amazingly buggy and/or
incomplete.  I'm slowly mastering it ... which means that I'm slowly
finding workarounds for at least the show-stopper bugs.  But I'm still
not confident that tomorrow won't bring a show-stopper that I _can't_
work around.


Just a thought -- rather than going through the Carbon-to-Cocoa API, would it be
easier/better to write the plugin in Java and use the Java-to-Cocoa interfaces?

Of course, not having a well-documented spec is a problem, but possibly one
could write some "glue" to support Sun's Java Plugin API, with Apple's
Java-to-Cocoa methods providing the connections to whatever places are needing
connected to? (I know, these are probably not documented, and would have to be
done via tiresome trial-and-error, but maybe there is a soul at Apple would
would think this approach is one worth supporting with hints?
(From comment 45)

> Just a thought -- rather than going through the Carbon-to-Cocoa API,
> would it be easier/better to write the plugin in Java and use the
> Java-to-Cocoa interfaces?

Do you mean what's documented in Apple's Application Kit and
Foundation "References for Java"?  As far as I can tell, this is just
a way to let you write Cocoa apps in Java, and has nothing to do with
(i.e. doesn't use) what's in the JavaVM Framework.


How do you guys intend to address the problem of this Java cocoa bundle drawing
in a Carbon/QuickDraw environment (which is what Mozilla is)? Carbon/Cocoa an
only be mixed at the window level. You can't mix Cocoa widgets with carbon
widgets in a window (WebKit is a special case, and the slew of problems that it
has show how hard it is).
(From comment 47)

> Carbon/Cocoa an only be mixed at the window level.

Do you mean that the same window can't contain both Carbon and Cocoa
"widgets" (that they must be placed in separate windows)?  As far as I
know Apple never says this explicitly (though if I'm wrong please cite
the source).  It's true that the CocoaInCarbon sample's Cocoa "user
interface" is indeed in a separate window.  But in "Integrating Carbon
and Cocoa in Your Application", in a section called "Creating an
NSWindow Object for the Carbon Window", there's a passing reference to
the fact that you can "create an NSWindow object for [a] Carbon
window" by doing the following:

cocoaFromCarbonWin = [[NSWindow alloc] initWithWindowRef:window];

That was my starting point in this whole adventure.

> (WebKit is a special case, and the slew of problems that it has show
> how hard it is).

I can personally attest that it _is_ hard :-)  But it's what needs to
be done, and I'm slowly making progress.


> Do you mean that the same window can't contain both Carbon and Cocoa
> "widgets"

Yes. We're heard this time and again from Apple, because we wanted to use
NSTextView in carbon. Apparently, WebKit only works because very special hacks,
and even then it has multiple problems (crashes, event handling issues, window
layering issues).

If you try embedding a cocoa widget in a carbon window, you'll run into the
following problems:

* Drawing and updating: the two drawing models are totally different. You'll see
  issues with coordinate systems, clipping, scrolling, and hiding and showing
  widgets (e.g. tab switching in mozilla).

  Drawing in Java is complicated by the fact that Java can draw on threads.
  The 1.3 API had calls to turn async drawing on and off; I don't know if those
  are available to you in 1.4.

* Event handling: you'll probably have issues with keyboard input (including
  TSM input), with mouse dragging, context menus etc. These will include issues
  getting the events to Java in the first place, and then issues with 
  coordinates, event modifiers etc.

* Runnning Cocoa in a Carbon app. Java 1.4 is totally Cocoa-based. That means
  that it can throw up Cocoa UI at unexpected times (e.g. security dialogs).
  If you don't have an NSAutorelease pool in place at these times, which you
  can't (without hacking Mozilla's main event loop and Carbon Event handlers),
  then this Cocoa UI that Java throws will cause all kinds of dire console
  warnings, and may crash. We've also seen these warnings leave all the
  menu items disabled in Camino; they basically hose the app.

I hate to be tbe bearer of bad news, but I think what you are attempting is
hard. Very hard.

The only workable solution I think is doable here is to get Java 1.4 working in
Camino (which is a Cocoa app, and uses an NSView-based rendering hierarchy).
Par(In reply to comment #49)

> I hate to be tbe bearer of bad news, but I think what you are attempting is
> hard. Very hard.

I hate to ask a stupid question, but ...

So why is it that 1.3 works and 1.4 doesn't? To this non-programmer, it sounds
like Java shouldn't be working in the browser at all!
Java 1.3 is Carbon-based, with a well-documented embedding API. 1.4 is
Cocoa-based with zilch on embedding documentation.
Thanks for the detailed response!  You haven't dissuaded me ... though
I agree that what I'm trying to do would be easier with Cocoa-based
browsers (though still not a piece of cake).  In a couple of spots
you've helped me out.

> * Drawing and updating: the two drawing models are totally
>   different. You'll see issues with coordinate systems, clipping,
>   scrolling, and hiding and showing widgets (e.g. tab switching in
>   mozilla).

As far as I know, I've got all these problems solved but the last one
-- I haven't yet figured out how to load an applet into one tab
without making it appear in all of them.  Interestingly, Mozilla has
problems with applets in tabs even using the Java Embedding Framework
(via the Java Applet plugin).  As I assume you already know, you can
make a Cocoa NSView use the Carbon coordinate system by overriding
isFlipped to make it return TRUE.  And you can do this in system
classes (i.e. not ones you wrote yourself) by using PoseAs.

>   The 1.3 API had calls to turn async drawing on and off; I don't
>   know if those are available to you in 1.4.

My (slightly imperfect) solution to this problem is to override
NSView's canDraw and make it return FALSE at the appropriate times.
This effects _all_ drawing operations -- even ones that are generated
internally to Java.  So I've got the Clock demo working correctly :-)

> * Event handling: you'll probably have issues with keyboard input
>   (including TSM input), with mouse dragging, context menus
>   etc. These will include issues getting the events to Java in the
>   first place, and then issues with coordinates, event modifiers
>   etc.

Yes, I've seen a bunch of these.  So far I've solved all of them with
Carbon event handlers.

>   Runnning Cocoa in a Carbon app. Java 1.4 is totally
>   Cocoa-based. That means that it can throw up Cocoa UI at
>   unexpected times (e.g. security dialogs).  If you don't have an
>   NSAutorelease pool in place at these times, which you can't
>   (without hacking Mozilla's main event loop and Carbon Event
>   handlers), then this Cocoa UI that Java throws will cause all
>   kinds of dire console warnings, and may crash. We've also seen
>   these warnings leave all the menu items disabled in Camino; they
>   basically hose the app.

This I haven't yet seen ... but thanks to you I now know what to look
for :-)  I suspect I can solve these problems by playing more clever
tricks with Carbon event handlers.

> The only workable solution I think is doable here is to get Java 1.4
> working in Camino (which is a Cocoa app, and uses an NSView-based
> rendering hierarchy).

I respectfully disagree.  But Mozilla will surely eventually get
ported to Cocoa, and when that happens things will get easier.  (I've
seen a lot of Cocoa code in the Mozilla source, though none of it is
currently in use.)


I hate to be the bringer of hacks, but I'll just throw this out there for
discussion.

If getting JavaPluginCocoa drawing in Mozilla winds up being just too Big, Mean,
and Nasty to get working, perhaps a proxy approach might work.

Roughly:  
mozilla <-> new proxy plugin <-> some-kind-of-IPC <-> background hidden Cocoa App

The background hidden Cocoa App just instantiates a JavaPluginCocoa and takes
its input from the mozilla plugin.  It sends back its window metadata and
graphics over some sort of IPC mechanism.  

I know, ewww, but as a java developer excited by Java 1.5 I don't want to see my
favorite browser on my favorite platform get left in the dust.  If Steven hits a
wall, getting it working as a kludge might be the best we can do.  If he doesn't
maybe more Cocoa bits can slowly creep in. :)
Since I really am missing Java I am going to make a suggestion, which based on
my limited programing knowledge may be tottally off base and if it is I am sorry
for wasting everyone's time.

Could an extension be built (i.e. like those under development at Mozdev) in
Cocoa which could access the 1.4.1 Java Plugin and thus provide Java
functionality to the browser in the form of an enxtension? I know this
workaround (if it is possible) would be an ankward fix for the Java issue for
Mac Mozilla. I am willing to accept any crude fix (as long as the browser is not
seriously crippled in the process) to bring Java 1.4.1 to Mozilla on MacOS X.
(In reply to comment #54)

You'd presumably still want the applets to appear "inline" (in the
same page with the other text and graphics).  So you'd still have to
mix Cocoa and Carbon "widgets" in the same page.  So you'd still have
to deal with the "Cocoa-Carbon interface".  So you'd still have all
the problems I've been having :-)
Flags: blocking1.8a?
(In reply to comment #55)
> (In reply to comment #54)
> 
> You'd presumably still want the applets to appear "inline" 

That's an interesting presumption. Certainly many java applets do not
necessarily need to be viewed inline. For those, something that merely sends the
URL to be handled by Java Web Start as a "helper application" might be an
acceptable work-around. 

It might even be a useful feature for *every* java plugin to have a "view
internally" and "view externally" option. 
(In reply to comment #56)

Interesting idea.  But I'm not sure what launching applets with a
helper application gains you ... besides providing a work-around for
problems with the Cocoa-Carbon interface on Mac OS X.

Also, this treatment would only be appropriate for an applet that was
in effect a stand-alone application.  It might be better to download
such an applet and run it like any other application -- though you'd
lose the security of the Java sandbox.

In any case, I'm going to keep banging away at the Cocoa-Carbon
interface.  I continue, slowly, to make progress.


There ia a freeware program MRJ Adapter
http://www.versiontracker.com/dyn/moreinfo/macosx/20705 .

Would this freeware program been of any help in getting the Java plugin to work?
Maybe this would help in porting a linux or windows Java plugin to the Mac? I an
not even sure if it can be made to work with plugins. Can someone who has better
programing skill look into this. Thanks.
Paul hit it right on the head.

The home page for this puppy: 
http://www.roydesign.net/mrjadapter/


What it does (all from the home page):
"Maybe I should drop the reference as well for MRJ Adapter, but until I do,
let's make it clear that MRJ Adapter is a library that allows your code to work
with any and all versions of Apple's Java virtual machine, from the oldest to
the latest and greatest."

"Supports Java 1.1 and up on all platforms, starting with MRJ 1.5 (Java 1.1) on
classic Mac OS all the way through JDK 1.4.2 on Mac OS X."

I think we've hit a gold mine, gentlemen!





(In reply to comment #58 and comment #59)

> I think we've hit a gold mine, gentlemen!

I don't think so.  The MRJ Adapter, while it looks like a valuable
contribution, is too high-level for our purposes.  It assumes a
working Java Virtual Machine ... but that's exactly what we don't
(yet) have -- at least for Java 1.4.X in browsers other than Safari.

Here's the inevitable progress report ... which is rather more
positive than (most of) the previous ones :-)

I actually now have something that's releaseable -- it works
reasonably well on Mozilla, Firefox and Camino, in both Jaguar and
Panther, on both Java 1.4.1 and 1.4.2.  All that remains is to update
the code comments and to write some docs.  In about a week I hope to
post a message here telling you all where to download the results of
my efforts.
Blocks: 232652
My Java Embedding Plugin is up on SourceForge!

http://javaplugin.sourceforge.net/

Please check it out.  And let me know what you think, here and/or in
one of the Java Embedding Plugin's public forums.

I'm particularly interesting in hearing about a couple of features I
haven't had a chance to test thoroughly:

In theory the Java Embedding Plugin has full support for TSM (Text
Services Manager) input (e.g. input methods for East Asian and Middle
Eastern languages), in both Carbon-based browsers (Mozilla and
Firefox) and Cocoa-based ones (Camino).  And Chinese language input
works just fine ... but I haven't had a chance to test anything else.

I _think_ the bugs I fixed in the MRJ Plugin Carbon have re-enabled
LiveConnect support in Mozilla and family, but I've only barely begun
to test this.


Steven,

First thanks for all your hard work bringing java to Mac Mozilla and family!

I tested the plugin JavaEmbeddingPlugin.bundle . I checked the pluinreg.dat file
and the OJI Plugin for Mac OS  and it was listed in the correct location second
last just before the Default Plug-in. Then I went to java test page:

http://www.java.com/en/download/help/testvm.jsp

and it reported that Java was not installed.  I unistalled the 
JavaEmbeddingPlugin.bundle leaving MRJ Plugin JEP installed. I returned to the
test page above and it reported that I had Java 1.3.1 installed.

I am using the Mozilla (Seamonkey) suite Moz 1.8a (Mozilla/5.0 (Macintosh; U;
PPC Mac OS X Mach-O; en-US; rv:1.8a) Gecko/20040418) running MacOS X 10.3.3 with
512MB on a G3 350 with Apple's Java 1.4.2 installed.

I look forward to having Java working :)
That page is giving an UnsatisfiedLinkError looking for the native method
nativeGetCookieInfo (sun.plugin.net.cookie.MacOSXCookieHandler.nativeGetCookieInfo).

I'm also getting some interesting behavior with the keyboard. When an applet has
been loaded, the system beeps whenever I press a key. It doesn't happen all the
time so I'm not completely sure what's going on.

On the plus side, the settings from the 1.4.2 plugin are the ones used by the JVM!
Attached image Screenshot (obsolete) — 

    
    

    
  
Then I went to java test page:
> 
> http://www.java.com/en/download/help/testvm.jsp
> 
> and it reported that Java was not installed.  I unistalled the 
> JavaEmbeddingPlugin.bundle leaving MRJ Plugin JEP installed. I returned to the
> test page above and it reported that I had Java 1.3.1 installed.
> 


I tried this test page and also get the info 1.3.1 installed. BUT: see the
attached screenshot Bild 2: Part of the testpage remains even when I switch the tab!
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; de-AT; rv:1.7b) Gecko/20040421

    
    

    
  
(In reply to comment #62, comment #63, comment #64 and comment #65)

I assume you're all talking about the same page:

http://www.java.com/en/download/help/testvm.jsp

I actually didn't know about this page, and had never tested on it
before.  But when I went to it in Mozilla 1.6 on Mac OS 10.2.8 with
Java 1.4.1, I had no problems.  (I'm temporarily unable to test in
10.3.3 or with Java 1.4.2.)  Over the next hour or two I'll test with
the combinations that you reported, and see what I get.  But I suspect
you have some variety of the plugins.dat problem (i.e. that it changed
after the last time you looked at it, if you did look at it).  If so,
the problem is _very_ widespread ... and even though it's not my
problem, I'll need to find a better workaround.

(In reply to comment #65)

> Part of the testpage remains even when I switch the tab!

Take a look at KnownProblems.txt :-)  None of the Mozilla family of
browsers correctly handle applets in tabs.



    
    

    
  
(In reply to comment #63)

I shouldn't have lumped your problem together with the rest -- your
browser appears to be using Java 1.4.2, not 1.3.1.  But I need more
information about the rest of your environment -- at the very least,
which browser and which version of Mac OS.

I myself have seen the MacOSXCookieHandler error before, but not on
this page.  I'll try to reconstruct which page(s) I saw it on and post
it or them here.

The keyboard error is interesting ... and a bit disturbing.  It might
be the result of a Carbon-Cocoa interface bug that I'm not yet aware
of (and for which I haven't yet found a workaround).

(In reply to comment #66)

> I actually didn't know about this page, and had never tested on it
> before.

I should have mentioned what I _did_ test on -- mostly the sample
applets that come with the JDK, plus other stuff that I've found on
Sun's applet page:

http://java.sun.com/applets



    
    

    
  
Comment on attachment 147222 [details]
Screenshot 

(In reply to comment #64)
> Created an attachment (id=147222)
> Screenshot 
> 

Martin, that's bug 162134.

        Attachment #147222 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #67)

I am using SeaMonkey 1.7b (1.7 RC1) under 10.3.3 with Java 1.4.2.

A bit more about the keyboard thing. I started with a window with several tabs
open. Went to an Applet page (both with and without console enabled) and then
closed that page. If I switch to another program, when I come back and use the
arrow key to scroll, type in the location bar, etc. each keystroke elicits a
beep. If I click in the browser window and try to scroll, it no longer beeps.
However, changing to another program and back again shows the same behavior. I
have not extensively tried different combinations of opening windows, tabs, etc.
If there is something I can do to help diagnose, let me now.

    
    

    
  
I see that same issue of keypresses going nowhere with many plugins. I think it
is a general browser focus problem and may be a red herring here. But then I
haven't had time to test this plugin yet, so I'm not certain what you are seeing
is the same thing I see with Quicktime, Flash, SchubertIT PDF, etc. 

    
    

    
  
congratulations, steven.
although your plug-in might not be perfect yet it works absolutely
satisfactingly for me. finally i can use the icq2go service which is based on java.
excelent work!! go on like that!
im working on os 10.2.8 with firefox and
http://www.java.com/en/download/help/testvm.jsp says that java 1.4.1 is
installed. i haven't noticed any of the mentioned bugs.
so the problems may really be a 10.3 only issue.

    
    

    
  
Steven, thanks for the work and effort you are putting into this. I was especially impressed by the fact 
that you are working on fixing LiveConnect, too. However, I'm experiencing some problems with this 
test page:

http://www.simonstl.com/dynhtml/update/code/chap6/lc1.html

I'm getting the following:

Java(TM) Plug-in: Version 1.4.2_04
java.lang.IllegalAccessError: tried to access method apple.awt.CAppletFrame.<init>(Ljava/awt/
Component;)V from class jep.MyCAppletFrame
	at jep.MyCAppletFrame.<init>(MyCAppletFrame.java:35)
	at jep.MyCToolkit.createFrame(MyCToolkit.java:56)
	at java.awt.Frame.addNotify(Frame.java:472)
	at java.awt.Window.pack(Window.java:436)
	at jep.AppletHolder.activateHolder(AppletHolder.java:291)
java.lang.UnsatisfiedLinkError: nativeGetCookieInfo
	at sun.plugin.net.cookie.MacOSXCookieHandler.nativeGetCookieInfo(Native Method)
	at sun.plugin.net.cookie.MacOSXCookieHandler.getCookieInfo(MacOSXCookieHandler.java:61)
	at sun.plugin.net.cookie.PluginCookieManager.getCookieInfo(PluginCookieManager.java:82)
	at sun.plugin.net.protocol.http.HttpURLConnection.connectSetup(HttpURLConnection.java:338)
        ...

I get this on all pages with applets. I should add that I'm running DP1 of Java 1.4.2 Update. Maybe they 
have changed the visibility of some methods? Or is this some permission policy thing? I'm on 10.3.3.

    
    

    
  
I've done some more testing ...

1) Running Java 1.3.1 instead of 1.4.X (in reply to comment #62 and
   comment #65)

I've now tested Mozilla 1.7rc1 on Mac OS X 10.3.3 with both Java 1.4.1
and Java 1.4.2, using the www.java.com testvm page and the Clock demo
-- I didn't have this problem once (though I've definitely had it
before under slightly different circumstances).

This is almost certainly a bug in Mozilla and family -- when I was
able to test with a debugging version of Mozilla 1.6 that I compiled
myself, I found that Mozilla wasn't even invoking the MRJ Plugin!  (My
new version of the latter, once invoked, will in turn invoke my Java
Embedding Plugin if it's present in "/Library/Internet Plug-Ins".)

But, like I said, the problem seems to be very common (at least on
10.3.3), which means that I'll have to try to do something about it.
I'll begin by using debugging versions of Mozilla to meticulously
trace its origin.

2) The MacOSXCookieHandler problem (in reply to comment #63 and
   comment #72)

Testing with the www.java.com testvm page, I never saw this with Java
1.4.1 (on either OS X 10.2.8 or 10.3.3).  But I always see it with
Mozilla 1.6 or 1.7rc1 with Java 1.4.2 (on 10.3.3 only, of course).
This one must ultimately be due to a problem with the Java Embedding
Plugin.  Now that I have a way to consistently recreate it, I should
be able to track it down.

3) The "Keyboard Thing" (in response to comment #63, comment #69 and
   comment #70)

I haven't yet tried to reproduce this, but Mike Calmus' detailed
observations in comment #69 give me something to work with.  Yes (wrt
to Joseph Delaney's comment), this may turn out to be a generic
browser (or Mozilla) problem.  But the Cocoa-Carbon interface has
thrown up enough similar problems to make that also a likely suspect.

4) The Illegal Access Error (in response to comment #72)

This is probably a bug in the Java Embedding Plugin.  Currently my
only fix for permissions problems is to put the Java Embedding
Plugin's jar file into xbootclasspath when starting the JVM.  But I
probably also need to explicitly give it "AllPermissions".

5) Congratulations! (in response to comment #71)

Thanks!

6) Misc (in response to comment #62)

Is there a Mozilla 1.8a?  I wasn't able to find one.



    
    

    
  
(In reply to comment #72)

> I was especially impressed by the fact that you are working on
> fixing LiveConnect, too.

Thanks! ... but I actually didn't set out to fix LiveConnect.  I
already have enough stuff on my plate :-)  Rather, I found fixes for a
couple of crash bugs that might (together) turn out to fix
LiveConnect, too.  See items 2 and 3 in the "Unrelated Bug Fixes"
section of my Changes-JEP.txt file (in the distro's
Source/MRJPluginJEP directory).



    
    

    
  
(In response to comment #73)

One thing I forgot to mention:

Sometimes this problem is worse (or insoluble) if you're running a
"locked" copy of Mozilla (as you would be if you were running it from
a mounted ".dmg" image).  Why this is I don't know ... but there must
be a setting that the browser can create in its "package" that helps
preserve the right plugin order once it's been established in the
"Library/Mozilla/plugins.dat" file.

> 1) Running Java 1.3.1 instead of 1.4.X (in reply to comment #62 and
>    comment #65)
>
> I've now tested Mozilla 1.7rc1 on Mac OS X 10.3.3 with both Java
> 1.4.1 and Java 1.4.2, using the www.java.com testvm page and the
> Clock demo -- I didn't have this problem once (though I've
> definitely had it before under slightly different circumstances).
>
> This is almost certainly a bug in Mozilla and family -- when I was
> able to test with a debugging version of Mozilla 1.6 that I compiled
> myself, I found that Mozilla wasn't even invoking the MRJ Plugin!
> (My new version of the latter, once invoked, will in turn invoke my
> Java Embedding Plugin if it's present in "/Library/Internet
> Plug-Ins".)
>
> But, like I said, the problem seems to be very common (at least on
> 10.3.3), which means that I'll have to try to do something about it.
> I'll begin by using debugging versions of Mozilla to meticulously
> trace its origin.



    
    

    
  
*** Bug 242543 has been marked as a duplicate of this bug. ***

    
    

    
  
An updated version (0.8.1) of my Java Embedding Plugin is up on
Sourceforge.

http://javaplugin.sourceforge.net

I _think_ I've fixed most of the problems people reported.  Please let
us all know your results.

(In reply to comment #73)

> 1) Running Java 1.3.1 instead of 1.4.X

It turns out that my advice about plugins.dat was completely
superfluous.  The real solution is much simpler -- you just need to
make sure that MRJPlugin.plugin's date is more recent than the dates
of either "Java Applet.plugin" or "Java Applet Plugin Enabler" (the
other two plugins that support the application/x-java-vm and
application/x-java-applet MIME types).

See the distro's Readme.txt and Changes.txt for more info.

> 2) The MacOSXCookieHandler problem

Problem solved by making sure the Java Embedding Plugin can always
load the libAppletsInCocoa.jnilib (which may be inside the
JavaPluginCocoa.bundle) if it's present.  See Changes.txt for more
info.

> 3) The "Keyboard Thing"

This one I haven't solved ... nor was I able to reproduce it.  But I
think I might be able to explain it.

Mozilla (and other apps) sometimes beep at you if you press a key in
the "wrong" context.  When you load an applet, the Java Embedding
Plugin (usually) gives the applet the keyboard focus, even if the
applet has no place for text input (the Java Embedding Plugin can't
know beforehand whether or not the applet wants keyboard input, so it
just assumes that it's best to give the focus to the applet you've
just loaded).  But if you click anywhere in the window's "content
area" outside the applet, it loses the keyboard focus.

The whole business gets more complicated when you use tabs (see below)
... though I've tried to make the Java Embedding Plugin behave the
same way when you load an applet into a tab.

> 4) The Illegal Access Error

My original response was wrong -- this is a method visibility problem,
not a permissions problem.  (Though it turns out that my solution (if
it is a solution) does require that I give JavaEmbeddingPlugin.jar
AllPermissions).)

Unfortunately, I haven't been able to install Java 1.4.2 DP1 on my
system, even after reinstalling the OS five or six times (with minor
variations).  So I don't know whether my "solution" will actually
work.  I'd very much like to hear from Anders Korsvall, and/or anyone
else who's managed to install DP1.

5) Applets in tabs

For a while I believed that none of the Mozilla family of browsers
supports applets in tabs ... which turns out to be wrong (thanks to
Bill McGonigle for submitting the link to bug 162134 that shows this).
It certainly _was_ true of older Mozilla versions running on Mac OS X,
but newer versions (like 1.6 and 1.7rc1) seem better behaved.

Seeing that it was actually worthwhile paying attention to applets in
tabs, I found some problems that I could address by changing the Java
Embedding Plugin.  But things still don't work perfectly, and I think
the problems are Mozilla's (though I need to do more testing to be
sure).  See Changes.txt and KnownProblems.txt for more info.

6) LiveConnect

I tried the link submitted by Anders Korsvall in comment #72
(http://www.simonstl.com/dynhtml/update/code/chap6/lc1.html), which is
a test of LiveConnect.  I found that it worked in either Java 1.4.1
(on OS X 10.2.8 or 10.3.3) or Java 1.4.2 (on 10.3.3).  I'd be curious
to hear more from others who are able to test more thoroughly.



    
    

    
  
Thanks again for the good work. The cookie issues are definitely resolved.

With respect to your statements about the "keyboard error". It does not appear
related to actual (or at least the full extent of) focus setting. I say this
because even admist the beeping, the actions I am expecting to happen do, in
fact, occur. When I type in the address bar, it beeps and inserts the characters
typed. If the focus were truly elsewhere, the characters would not be inserted.
Further, it continues even after all applet windows are closed. Simply having
the JVM load seems to cause the issue.

    
    

    
  
(In response to comment #78)

> Thanks again for the good work. The cookie issues are definitely
> resolved.

Thanks!  And glad to hear it.

> With respect to your statements about the "keyboard error". It does
> not appear related to actual (or at least the full extent of) focus
> setting. I say this because even admist the beeping, the actions I
> am expecting to happen do, in fact, occur. When I type in the
> address bar, it beeps and inserts the characters typed. If the focus
> were truly elsewhere, the characters would not be inserted.
> Further, it continues even after all applet windows are
> closed. Simply having the JVM load seems to cause the issue.

Interesting.  I still don't understand the problem ... but new details
are slowly accumulating :-)

Here's another hunch:  It's possible that your keyboard focus is in
two different places at once (one in a Carbon context, the other in a
Cocoa context) -- one of them beeps at you, while the other accepts
your keystrokes and interprets them.

I saw this several times as I was writing the Java Embedding Plugin,
and each time I added code to one of my handlers (in this case either
routeEvent in Controller.m or HandleFocus() in Handlers.m) to squelch
it (since it clearly isn't desirable behavior).  It's possible I
missed one of the ways this might happen.

Is there _anything_ unusual about how keyboard input is handled on
your system?

Also, it might help if you do the following:

Open a Terminal session and run Mozilla from the command line (by
changing to the Contents/MacOS directory and entering
"./mozilla-bin").  This makes Terminal act like a console, which means
you might see some interesting messages.



    
    

    
  
Your premise about the different contexts for focus sounds quite likely.

The only output I get is this:

./mozilla-bin: can't map file: /Library/Internet Plug-Ins/MRJPlugin.plugin
((os/kern) invalid argument)
### MRJPlugin:  getPluginBundle() here. ###
### MRJPlugin:  CFBundleGetBundleWithIdentifier() succeeded. ###
### MRJPlugin:  CFURLGetFSRef() succeeded. ###
## Component Manager: attempting to find symbols in a component alias of type
(regR/carP/x!bt)

    
    

    
  
Steven,
Thanks for all your good work. The plug in appears to work when I go to this
test page http://www.java.com/en/download/help/testvm.jsp although the display
page does not display correctly. I am providing a screenshot. 

I believe I have encountered two bugs that appear once the plugin has been
loaded (i.e. only after I have gone to the test page above):

  1. Double clicking on the title bar at the top of the Mozilla window fails to
minimize the window and send it to the dock. Clicking on the yellow '-' widget
will still minimize the window and send it to the dock.

  2.  The JavaEmbeddingPlugin.bundle file conflicts with the Wacom Tablet
wireless mouse (the one which sits on top of the the Wacom drawing tablet). The
plugin somehow disables the scroll wheel on the mouse. The scroll when continues
to work on other applications such as TextEdit.

The plugin seems to be "almost" here.

    
    

    
  


  
Mozilla doesn't display the test page correctly.

    
    

    
  
Sorry for the extra emailbut maybe you might want my system configuration which
I forgot to provide:

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a) Gecko/20040509

G3 B/W 350mhz MacOS X 10.3.3

    
    

    
  
Steven,

Let me also thank you for all of your time and hard work that you have dedicated
to this project and to the Mac Mozilla community as a whole. I've got some
screenshots that may or may not be of interest to you, using today's 0.8 branch
build of Camino: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7)
Gecko/20040508 Camino/0.8b . Pictures 2 and 3 come from the same page, Gemal's
Browserspy page, 1 is from a Sun Java tutorial page, and 4 is from the
afformentioned test page from above. Notice on Gemal's page that it shows Java
1.3.1 enabled (Bug 97613 fixed as a result of your work?), but lists Java 1.4.2
below. In Picture 4, the little guy was dancing around, he just didn't show up
in the screenshot.

Mac OSX 10.3.3, iMac 400 DV SE, 1 GB RAM

http://home.comcast.net/~joelcraig23/images/Picture_1.pdf
http://home.comcast.net/~joelcraig23/images/Picture_2.pdf
http://home.comcast.net/~joelcraig23/images/Picture_3.pdf
http://home.comcast.net/~joelcraig23/images/Picture_4.pdf

    
    

    
  
In further testing on the same pages as above, behavior is the same in the May 9
build of Firefox, and Mozilla 1.7 RC 1, on the iMac as well as my 12" PB 1Ghz,
10.3.3, 1.25GB RAM.

    
    

    
  
Noticed one problem specific to Camino. Loading a local java radar animation at
http://weather.gov/ locks up the app, with no ability to scroll the page and
having to Force Quit. Works fairly decently in Mozilla, don't have Firefox on my
PB and I'm laying in bed as I type this, but I'd assume FF would work similarly
to Mozilla.

    
    

    
  
I've noticed that Java Embedding Plugin has a problem with signed applets.
I use Mozilla browser v1.7b

When signed applet is loaded before security dialog box shows up,
this null pointer exception happens:

java.lang.NullPointerException
	at java.awt.Container.insets(Container.java:284)
	at java.awt.Container.getInsets(Container.java:274)
	at java.awt.BorderLayout.preferredLayoutSize(BorderLayout.java:587)
	at java.awt.Container.preferredSize(Container.java:1178)
	at java.awt.Container.getPreferredSize(Container.java:1162)
	at java.awt.Window.pack(Window.java:438)
	at jep.AppletHolder.activateHolder(AppletHolder

and applet screen stays blank.

I use embed tag to load an applet for Mozilla browser and it works
for Windows Mozilla and Mac Mozilla without Java Embedding Plugin(when I remove 
it from /Library/Internet Plug-Ins folder)

My signed applet works with Safari, although 'applet' tag is used to load an 
applet.

Also I've noticed that the same exception is thrown when connecting to
http://segal.org/java/hellotrust/ where signed applet is placed(on Mac Mozilla 
plus Java Embedding Plugin).

My environment is:

MAC OSX 10.3.3(7F44)
[PowerPC/G4 450 MHz/256 MB]


    
    

    
  
(In response to comment #80)

The "can't map file" line and those starting with "### MRJPlugin" are
normal.  (The "can't map file" error happens all the time on Mac OS X
and seems completely benign.  Bugzilla has a couple of reports on it.
Search using "can't map file".)

The "## Component Manager" line might be a clue, but I haven't yet had
time to try to follow it.

It'd be very interesting to see if you can reproduce your problems in
Camino or Safari.  (Before using Camino you'll need to move its own
copy of the MRJPlugin to the "plugins-disabled" folder, as described
in the Java Embedding Plugin Readme.  The Java Embedding Plugin
contains a lot of Carbon-specific code that doesn't get used with a
Cocoa browser like Camino.)



    
    

    
  
(in response to comment #88)

I do not experience the keyboard issue while ussing (an admittedly old copy of)
Camino. It works just fine.

    
    

    
  
(In response to comment #89)

> I do not experience the keyboard issue while ussing (an admittedly
> old copy of) Camino.  It works just fine.

Oh, well.  But it seems to confirm that the problem's Carbon-specific
(and that my hunch about two simultaneous keyboard focuses may be
right).

This is going to be a very hard problem to solve.  But I'll keep it in
mind, and maybe it'll provide the clue I need to solve some other,
related (and better understood) problem -- so that I'll be able to
solve them both at once.



    
    

    
  
(In response to comment #81 and comment #82)

> Thanks for all your good work.

You're quite welcome.

> Mozilla doesn't display the test page [www.java.com's testvm.jsp]
> correctly.

I assume you're talking about the way the text is cut off to the left.
But this also happens in Safari.  It must be a problem with Apple's
JVM or with the applet.

> Double clicking on the title bar at the top of the Mozilla window
> fails to minimize the window and send it to the dock. Clicking on
> the yellow '-' widget will still minimize the window and send it to
> the dock.

I can confirm what you say about double-clicking on the Mozilla
window's title bar -- this (mis)behavior is clearly caused by the Java
Embedding Plugin.  I'll see what I can do about it.

But I don't have any problems with the "yellow '-' widget" (Apple
should just call it the minimize button, but maybe they're afraid
that'll offend Bill).  The double-click problem is "per-window" -- It
only happens after you've loaded at least one applet into a window,
and it doesn't happen in a new window until you've loaded an applet.
Is this also true of the minimize button problem?

> The JavaEmbeddingPlugin.bundle file conflicts with the Wacom Tablet
> wireless mouse (the one which sits on top of the the Wacom drawing
> tablet). The plugin somehow disables the scroll wheel on the
> mouse. The scroll when continues to work on other applications such
> as TextEdit.

This will be hard to fix :-(  There's not much chance that I'll ever
own a Wacom Tablet.  But I'll keep it in mind, and maybe some other
fix will also solve this problem.



    
    

    
  
(In response to comment #84 and comment #85)

> Let me also thank you for all of your time and hard work that you
> have dedicated to this project and to the Mac Mozilla community as a
> whole.

Thanks!

> Picture 1
> [http://java.sun.com/docs/books/tutorial/applet/practical/properties.html]

I get the same results loading this applet in Mozilla (with the Java
Embedding Plugin), Safari, and even Mozilla (1.6) on Windows!

  java.lang.ClassNotFoundException: GetOpenProperties.class

It's a problem with the applet.  (By the way, _lots_ of applets on
Sun's pages are broken, and there are also many broken URLs.  It's as
if Sun had stopped paying attention to applets for the last couple of
years.)

> Pictures 2 and 3 [http://gemal.dk/browserspy/java.html]

> Notice on Gemal's page that it shows Java 1.3.1 enabled (Bug 97613
> fixed as a result of your work?), but lists Java 1.4.2 below.

I think it's just a logic error in the applet.  I get the same results
in Safari (though not in Mozilla 1.6 with Java 1.4.1 on Windows).

> [Lines that should display off the bottom of the page overwriting
> lines already displayed]

This problem I _don't_ see in Safari.  And I don't see it in Mozilla,
either, if I make the page large enough (it doesn't have to be large
enough to contain all the lines).  However I suspect that it, like the
problem in Picture 4, is a problem in Apple's JVM or in the applet.

> Picture 4 [http://www.java.com/en/download/help/testvm.jsp]
> [Lines cut off to the left]

As I said in response to Paul Bergsagel's message, this also happens
in Safari.  It must be a problem with Apple's JVM or with the applet.



    
    

    
  
(In reply to comment #86)

> Noticed one problem specific to Camino. Loading a local java radar
> animation at http://weather.gov/ locks up the app, with no ability
> to scroll the page and having to Force Quit. Works fairly decently
> in Mozilla, don't have Firefox on my PB and I'm laying in bed as I
> type this, but I'd assume FF would work similarly to Mozilla.

I didn't have this problem (with either Camino (0.7) or Mozilla
(1.7rc1), on either Mac OS X 10.2.8 with Java 1.4.1 or 10.3.3 with
Java 1.4.2.

Does your crash happen every time?

But I _did_ have another, wierd, problem that resembles (a bit)
something Paul Bergsagel reported in comment #81:  In Camino (0.7),
after I started looping, the minimize button and its two companions
(in the upper left) were disabled (the were unusable and mousing over
them didn't make them change)!  This happened twice -- once on Mac OS
X 10.2.8 with Java 1.4.1 and once on 10.3.3 with Java 1.4.2.  The
second time (on 10.3.3) Camino's entire menu became disabled, and I
had to kill it from the command line!

From things I've seen as I wrote the Java Embedding Plugin, I suspect
this is because the code in Apple's JVM that supports modal windows is
badly broken.  At first I thought it was a problem only with the
Cocoa-Carbon interface, so my fixes are only invoked when running
Mozilla or Firefox.  From this (and a few other things I've seen), I
now realize that I should try enabling those fixes even for Cocoa
browsers.

Why, you ask, should modal windows be involved?  In both my Java
environments (1.4.1 and 1.4.2) I've set Java to "Show Exception Dialog
Box" (which is a modal window).  The National Weather Service applets
send a banner message to the console after they've loaded, which might
(sometimes or always?) get interpreted as the text of an exception
message.



    
    

    
  
(In response to comment #87)

> Also I've noticed that the same exception is thrown when connecting
> to http://segal.org/java/hellotrust/ where signed applet is placed
> (on Mac Mozilla plus Java Embedding Plugin).

I didn't have any problems with this link.  I tested on Mac OS X
10.3.3 with Java 1.4.2, in Mozilla 1.6, 1.7rc1 and Camino 0.7.

For what it's worth, the Java security dialogs are modal windows.  As
I mentioned in the previous comment, Apple's JVM's code for modal
windows is very buggy.  I have fixes for at least some of the bugs in
the Java Embedding Plugin, which get invoked in a Carbon browser (what
you're using).  Maybe there are some bugs that I missed.



    
    

    
  
I can duplicate Camino lock-up everytime on this page:

http://www.crh.noaa.gov/radar/loop/DS.p19r0/si.klot.shtml

Works fine on Mozilla 1.7 RC1 and Firefox May 9 nightly. Unfortunately, not
getting anything in the Console or Crash Log, just a complete lock-up:

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040508
Camino/0.8b

    
    

    
  
The trumcated text issue with the Sun test page is neither a bug in Apple's JVM
nor in the Applet. Instead, it is a sizing issue on the web page. When I make
the applet width in the page wider, the text is displayed. It seems more or less
to be an issue with font sizes using the 1.4 JVM.

    
    

    
  
>Here's another hunch:  It's possible that your keyboard focus is in
>two different places at once (one in a Carbon context, the other in a
>Cocoa context) -- one of them beeps at you, while the other accepts
>your keystrokes and interprets them.

I can almost guarantee that it's the Cocoa one that's beeping at you.  If someone gets into this state, 
attach in gdb and break on SysBeep and NSBeep.  I bet the NSBeep will be hit.  Cocoa is what beeps at 
you when you type something it doesn't expect (and that bugs the heck out of me).

    
    

    
  
(In response to comment #95)

I did my tests over again with Camino 0.8a (what you've been using),
and got the same results -- no crash, but the three top-left widgets
(gum balls?) and all of Camino's menu were disabled.

The rest of my environment is (and was) OS X 10.3.3 with Java 1.4.2.

The same thing happened with all four combinations of the Java Console
and Exception Dialog Box (show or don't show).

I'd be curious to hear what results other people get.



    
    

    
  
(In response to Comment #97)

I did as you suggested. gdb does in fact break on NSBeep. If someone could give
me a little tutelage on gdb, I can provide more info.

    
    

    
  
(In response to comment #96)

> When I make the applet width in the page wider

How do you do that?  I see the truncation even when I make the browser
window (Mozilla, Camino or Safari) fill the whole screen ... but I
don't suppose that's what you're talking about.



    
    

    
  
(In response to comment #99)

Here's how I'd do it:

At the gdb command prompt enter the following to see how many threads
are running:

  info threads

Then for each thread enter each of the following:

  thread n
  backtrace

You'll end up with a stack trace for each running thread.



    
    

    
  
(In response to Comment #100)

Sorry. I downloaded the .class file and made my own enclosing web page. In the
APPLET tag itself is where I adjusted the width.



    
    

    
  

      
      
      
      

        Attached file
          
        GDB output on NSBeep
        — 
      

    


  
(In response to Comment #101)

Here is the thread output when Mozilla breaks on NSBeep. I hope this helps.

    
    

    
  
I think what you guys are talking about is covered by bug 168549. This happens
because Java is throwing Cocoa dialogs from threads with no NSAutoreleasePool in
place (look for console output).

    
    

    
  
For comment 101.. you don't have to do all of that work.  You can simply say:

thread apply all bt

(or I think even "t a a bt") and it'll get 'em all in one command.

    
    

    
  
I can get this up and running with Camino, the
http://www.java.com/en/download/help/testvm.jsp page shows it is running Java
1.4.1_08. But when I try it in Mozilla and firefox I get nothing - the applet
stays blank. The about:plugin page shows the plugin is loaded as the first in
the list after the default plugin, the enable java option is on, and I tried a
couple of different sites. I even dragged the old "java applet.plugin" and
enabler out of the plugins folder but that did not help. 

This is on MacOS 10.2.8 on a G4 Cube, with Mozilla 1.7rc1 and 1.6, and Firefox
0.8. I do see the messages in console when each browser starts up that indicates
the plugin is loading:

/Users/jpd/Desktop/Mozilla.app/Contents/MacOS/mozilla-bin: can't map file:
/Library/Internet Plug-Ins/MRJPlugin.plugin ((os/kern) invalid argument)
### MRJPlugin:  getPluginBundle() here. ###
### MRJPlugin:  CFBundleGetBundleWithIdentifier() succeeded. ###
### MRJPlugin:  CFURLGetFSRef() succeeded. ###
/Users/jpd/Desktop/Camino.app/Contents/MacOS/Camino: can't map file:
/Library/Internet Plug-Ins/MRJPlugin.plugin ((os/kern) invalid argument)
### MRJPlugin:  getPluginBundle() here. ###
### MRJPlugin:  CFBundleGetBundleWithIdentifier() succeeded. ###
### MRJPlugin:  CFURLGetFSRef() succeeded. ###
/Users/jpd/Desktop/Firefox.app/Contents/MacOS/firefox-bin: can't map file:
/Library/Internet Plug-Ins/MRJPlugin.plugin ((os/kern) invalid argument)
### MRJPlugin:  getPluginBundle() here. ###
### MRJPlugin:  CFBundleGetBundleWithIdentifier() succeeded. ###
### MRJPlugin:  CFURLGetFSRef() succeeded. ###


    
    

    
  
Oops, sorry - logging out and back in again cleared that up. I should have tried
that before posting.

    
    

    
  
(In response to comment #104)

> what you guys are talking about

I don't know what you're referring to (since we've been talking about
a large number of different things).  But since bug 168549 concerns
Camino, I'll assume that it's the problems a couple of us have had
with the National Weather Service's radar looping applets,
specifically at the following link:

http://www.crh.noaa.gov/radar/loop/DS.p19r0/si.klot.shtml

> This happens because Java is throwing Cocoa dialogs from threads
> with no NSAutoreleasePool in place (look for console output).

Not in my case, at least.  As your comment 8 to that bug says, the
hallmark of the "no NSAutoreleasePool in place" problem is a bunch of
error messages that look like the following:

  *** _NSAutoreleaseNoPool(): Object 0x3d07e00 of class NSCFArray
  autoreleased with no pool in place - just leaking

When I run Camino from the command line in a Terminal session and run
one of the NOAA's looping applets, I still get the problems I reported
in comment #93 and comment #98, but nothing unusual at the console
(and particularly no NSAutoreleaseNoPool messages).

As I was writing the Java Embedding Plugin I saw a bunch of cases
(usually in Mozilla or Firefox instead of Camino) where menus were
partially or totally disabled after the JVM had put up a modal dialog
and I dismissed it.  None of them resulted from not having an
autorelease pool in place.



    
    

    
  
(In response to comment #103)

Thanks for the info!  (And I agree with Matt Ackeret (comment #105)
that it would have been a lot easier to enter "thread apply all bt".
I don't use gdb a whole lot, and didn't know that.)

But I'm not able to glean much from it.

The stack trace for thread 1 does contain information specific to the
Java Embedding Plugin.  But as far as I can tell there's nothing
unusual or interesting in any of the other threads.

The stack trace for thread 1 refers to line 395 of Handlers.m -- a key
event is being processed by HandleFocus(), and CallNextEventHandler()
has just been called (which passes the event to the "Cocoa event
handler").  After CallNextEventHandler() returns, the next block of
code will decide whether to return "noErr" from HandleFocus() (which
tells the OS the event has been handled -- in effect that it can now
be swallowed), or "eventNotHandledErr" (which tells the OS to pass the
event to handlers that were installed before the "Cocoa event handler"
-- i.e. to the browser's or some other app's Carbon handler or event
loop).

From what you report, HandleFocus() will return "eventNotHandledErr"
and Carbon code will process the key event.

Like I said, that's not much :-)

I'm not sure where to go next -- possibly you could set another
breakpoint at NSBeep(), and this time run "ps aux" (outside of gdb) to
get a list of all processes currently running on your system.



    
    

    
  
(Following up on comment #109, comment #69 ...)

One more observation on your stack traces:

> From what you report, HandleFocus() will return "eventNotHandledErr"
> and Carbon code will process the key event.

This is an unexpected result.  If CallNextEventHandler() feeds the key
event to a Cocoa context (which the call to NSBeep shows that it
does), the (Cocoa context) keyboard focus should be somewhere in an
applet, and [JEPController windowHasKeyWindow] should return TRUE --
which means that HandleFocus() should return "noErr", and the Carbon
code should never see the key event.

That is, unless you're pressing Command, Option and/or Control (which
would make controlModifiers positive), or a second window is somehow
involved (which would make GetUserFocusWindow() return something
unexpected).  Could either of these things be happening?

A side note:

You've never given examples of applets where you can get the "keyboard
thing" to happen, so I've had to assume any applet would do.  Can you
give me URLs for some examples?



    
    

    
  
(In response to Comment #110)
The applet doesn't matter. In fact, an applet doesn't even have to be loaded.
This happens once the JVM has loaded (but not before) regardless of whether or
not an applet is active.

Presseing a control key does not seem to matter. I've had it occur simply with
the keypress. I've also had it happen trying to use CMD-T to create a new tab.

(In response to Comment #109)
What exactly are you looking for in the process list? I've got dozens of apps
and processes running so giving the whole list is probably excessive.

    
    

    
  
(In response to comment #111)

> This happens once the JVM has loaded (but not before) regardless of
> whether or not an applet is active.

Some of the Java Embedding Plugin's code is loaded with the JVM, and
stays loaded until you quit your browser (the AppleEvent TSM handler
and the "application" handlers, in Handlers.m).  Other code gets
loaded "per window" -- as soon as you load the first applet into a
window.

Also, the only way to load the JVM is to load an applet, so I'm not
entirely sure what you mean by "whether or not an applet is active".

Anyway, here are two scenarios.  If the first matches what you see,
there are (presumably) problems with the code that stays loaded until
you quit the browser.  If the second matches, then the problems are in
the code that gets loaded "per window".

First scenario:  The "keyboard problem" doesn't happen until you load
at least one applet into one window.  Then you can destroy the applet
by going to another URL, but the problem keeps happening.  It can
happen in a new window, where you've never (yet) loaded an applet.
The problem goes away if you quit the browser and restart it -- until
you load at least one applet into one window.

Second scenario:  The "keyboard problem" doesn't happen in any
particular window until you load an applet into it.  After you've
loaded an applet into one window, it will happen when the focus is in
that window.  You can destroy the applet by going to another URL in
the same window, but the problem keeps happening.  If you open another
window and keep the focus there, the problem won't happen until you
load at least one applet into that window.  The problem goes away
entirely if you quit the browser and restart it.

If neither scenario matches, the "keyboard problem" is probably not
caused by the Java Embedding Plugin -- though it may trigger the
problem in a fashion that may be impossible to trace.

> What exactly are you looking for in the process list? I've got
> dozens of apps and processes running so giving the whole list is
> probably excessive.

The problem is I don't know :-)  You might try temporarily stopping
some of those apps to get your system down as close as possible to
"plain vanilla" (mine is very plain vanilla).  See if the problem goes
away.  Then add each of your apps back, one by one, and see which one
triggers the problem.



    
    

    
  

      
      
      
      

        Attached file
          
        Processes running
        — 
      

    


  
This is the list of processes running when the break occurs. I quit all
applications besides Finder and Terminal before running.

The problem fits into scenario 2 and occurs on a per window basis exactly as
you describe.

    
    

    
  
(In response to comment #113)

You've still got three things running that might, conceivably, be
interfering:

1) Apache (with Tomcat, which uses Java)
2) "Microsoft Mouse.app"
3) "WeatherPop.app"

I don't know if stopping #2 will make your mouse unusable.



    
    

    
  
(In response to Comment #114)
After killing off Apache, Tomcat, etc. the behavior does not change.

    
    

    
  
Back to the applet at:

http://www.crh.noaa.gov/radar/loop/DS.p19r0/si.klot.shtml

In addition to completely disabling Camino, I've found that in Firefox (using
May 10 nightly, same behavior in May 9 nightly as well) and Mozilla 1.7 RC1,
loading the plugin is disabling the scroll wheel on my Kensington Iridio mouse.
Scrolling does NOT come back until you QUIT the browser and restart it. Simply
going to a page with no java results in the scroll wheel still being disabled.

    
    

    
  
Steven, this version of the plugin no longer experiences the java.lang.IllegalAccessError problem. 
However, on 1.4.2 Update 1 I'm getting the following exception when launching an applet (all applets 
generates the same error):

java.lang.NullPointerException
	at java.awt.Container.insets(Container.java:284)
	at java.awt.Container.getInsets(Container.java:274)
	at java.awt.BorderLayout.preferredLayoutSize(BorderLayout.java:587)
	at java.awt.Container.preferredSize(Container.java:1178)
	at java.awt.Container.getPreferredSize(Container.java:1162)
	at java.awt.Window.pack(Window.java:438)
	at jep.AppletHolder.activateHolder(AppletHolder.java:284)

On 1.4.1 and OS 10.2 the applets work fine. Even the LiveConnect test case I mentioned previously. 
However, our own application (that uses LiveConnect) gets null when calling JSObject.getWindow(this). 
That may have to do with our applet being in a frameset, but I'll try to create a minimized test case.

I'm using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040206 Firefox/
0.8

    
    

    
  
(In response to comment #115)

I was afraid you'd say that.

As things now stand, I don't have enough information to resolve the
"keyboard problem", and don't know where to ask you to look for more.
It does seem that the Java Embedding Plugin is involved, and may be
the cause.  But I'm going to have to put the problem aside for the
time being.  I've got a couple of other problems that I'm actually
able to reproduce.  With luck, after having fixed them (and others
...) I'll have enough extra insight to tackle your problem again.

Thanks for all your reports.  Sorry they didn't lead to a better
result :-(



    
    

    
  
(In response to comment #116)

Take a look at what I say in comment #112 about the different parts of
the Java Embedding Plugin handler code, and how the etiology of a
problem will be different if the cause lies on one part or the other.
Does your scrolling wheel problem match "Scenario 1", "Scenario 2" or
none of the above?

Does it get disabled by _any_ applet, or only by the NOAA radar
looping applets?

Someone else (comment #81) also reported a problem with a scrolling
wheel.  I don't currently have such a mouse (though I do have one with
three buttons).  I may actually go buy one (I don't believe they're
expensive).  But until that happens there's not much I can do beyond
collect data.

By the way, I'm still able to consistently reproduce my problem with
the NOAA applets that I talked about in comment #93, comment #98 and
comment #108.  I know it's not identical to yours, but it's close
enough that there's a good chance of solving both problems at once.  I
haven't made much progress ... though I _have_ managed to rule out the
JVM's modal windows as a cause :-(



    
    

    
  
(In response to comment #117)

Thanks for letting me know that my fix for the method visibility
problem in Java 1.4.2 Update 1 DP1 actually worked!  But sorry to hear
that's not the end of the story.

> java.lang.NullPointerException
>       at java.awt.Container.insets(Container.java:284)
>       at java.awt.Container.getInsets(Container.java:274)
>       at java.awt.BorderLayout.preferredLayoutSize(BorderLayout.java:587)
>       at java.awt.Container.preferredSize(Container.java:1178)
>       at java.awt.Container.getPreferredSize(Container.java:1162)
>       at java.awt.Window.pack(Window.java:438)
>       at jep.AppletHolder.activateHolder(AppletHolder.java:284)

Peter Tolmachov reported an identical exception in comment #87, but
said (or rather implied) that it only happens with signed applets.  I
wasn't able to reproduce it (comment #94).  He didn't say what version
of Java he has.

As I said in comment #77, I've been unable to install Update 1 DP1,
and will probably have to wait for a (hopefully less buggy) DP2.  But,
as I did before, I'll take a look at the Java classes listed in this
exception.  I may once again get lucky.



    
    

    
  
Sorry to tangent, but Comment 119 mentions a scroll wheel.  You don't actually have to get a real 
scroll wheel mouse.  There's an excellent (IMHO) addition called uControl (http://www.gnufoo.org/
ucontrol/) that simulates scroll wheels with mouse movement + customizable modifier.  I use it with 
my "Apple Keyboard" (the one that shipped with the SE) and my trackball on this dual-G4 I'm typing 
on.  (Through ADB<>USB converter of course.)  Now that I've tried uControl, I really like the simulated 
scrolll wheel.

This probably would also suffice to try and reproduce any problems with real scroll wheels.

    
    

    
  
(In response to comment #121)

Thanks for the suggestion.  I'll try it out.

But here's the inevitable question:

Does _your_ (virtual) scroll wheel get disabled when you load one of
the NOAA radar looping applets, or any applet? :-)



    
    

    
  
In addition to the looping NOAA weather radar, the following applets also
disabled the scroll wheel on my Kensington mouse until quitting both Firefox and
Mozilla 1.7 RC1:

http://www.java.com/en/download/help/testvm.jsp
http://www.dslreports.com/stest?loc=97
http://java.sun.com/docs/books/tutorial/applet/practical/properties.html
http://gemal.dk/browserspy/java.html
http://www.thedividingline.com/

Scrolling ability is NOT lost in Camino.




    
    

    
  
Additional to Comment 123:

The NOAA radar is the ONLY applet that disables Camino. The applets I listed
above DO NOT disable Camino, nor do I lose scrolling ability.

    
    

    
  
(In response to comment #123 and comment #124)

Thanks for the info ... but you didn't answer another of my questions
(from comment #119):

> Take a look at what I say in comment #112 about the different parts
> of the Java Embedding Plugin handler code, and how the etiology of a
> problem will be different if the cause lies on one part or the
> other.  Does your scrolling wheel problem match "Scenario 1",
> "Scenario 2" or none of the above?



    
    

    
  
If I exchange "keyboard problem" with "scrolling problem", Scenario #2 most
closely matches what's going on. I opened 2 windows in Firefox, loaded an applet
into one of them. When focus was on the page WITH the applet, scrolling was
disabled. When I switched focus back to the page WITHOUT the applet, scrolling
via scroll wheel was still active. Of course, going to another URL without an
applet did not re-activate scrolling in the applet page. Hope this helps.

    
    

    
  
Additional to Comment 126:

The same can NOT be said for Camino, however. Again, opening 2 windows, one of
them to this page, the other again to our NOAA radar loop. Of course, the loop
locked up Camino. Brought this Bugzilla page to the front, however, the applet
page retained focus and I had to force quit the app. Scenario #1?

    
    

    
  
(In response to comment #126 and comment #127)

Thanks again for the info.  It really does help.  But I should have
made clearer that the "scenarios" question applies only to
Carbon-based browsers -- i.e. to Mozilla and Firefox, but not to
Camino.



    
    

    
  
Hello everybody,

I have done quite a bit of testing with home-grown applets, and I find the
results  very impressive: our application is overall usable already, which
wasn't obvious.

To give you an idea, we are a small company developing laboratory information
software for the biotech industry. Our flagship product is java-based to support
heterogeneous environment (the Mac being strong in the biotech community). Bugs
in Safari and obligation to upgrade our customers to Panther to have them fixed
made us really anxious 1.4.x would be usable with alternate browser.

The software has over 20 different signed applets, totalling nearly 30k lines of
code, using swing, a lot of RMI, file and network I/O, etc...
I haven't been through all of the features, but as I said, it seems usable, at
least on 10.2.8 with Firebird. I will test on 10.3.3/Java 1.4.1 later.

I can report on two minors bugs that I have seen, and I believed have already
been singled out:
- cropping of the applet graphics: we open new html windows with new applets
embedded inside. sometimes the new page doesn't open with the right size (to be
investigated on our side) and crops the applet. Then even if I resize the
browser window, the cropped part is never refreshed, it remains cropped even for
new items drawn in that part.
- mouse clicks only result in beeps in a dialog with a combo-box and OK/dismiss
buttons. It is impossible to make a choice, and the dialog can only be dismissed
with the "close" widget (red button) once a mouse click has been made in it.
However, I noticed that if I browse the combo-box with the keyboard arrow-keys
and make my choice with the return key, I can work through it perfectly. Would
get tricky though if the dialog had more sophisticated inputs.

Congratulations, keep on that terrific job !

    
    

    
  
I have a few issues.

1) Buttons in one of my applets are rendered with an (incorrect) black background.
2) Some images in applets are poorly rendered.
3) Applets can cause Firefox (0.8) to lock up and require a "force quit".
    The gdb trace, below, was taken with Firefox locked.  The latter problem also 
    occurs in Safari -- I've reported it to Apple tech support -- which also locks
    waiting for a semaphore. (Windows and Linux platforms do not lock up.)

I have a test case but it requrires a userid and password which I do not wish to post on a public forum.  
I would be willing to provide privatly if needed.

0x90017048 in semaphore_wait_signal_trap ()
(gdb) bt
#0  0x90017048 in semaphore_wait_signal_trap ()
#1  0x9000e890 in _pthread_cond_wait ()
#2  0x909f1b3c in -[NSRecursiveLock lock] ()
#3  0x92de83d4 in -[NSView addSubview:] ()
#4  0x03725020 in -[JEPController createDummyTextView] (self=0x6b24900, _cmd=0x37349e0) at 
Controller.m:1565
#5  0x0372645c in -[JEPController fixDisplayOnMainThread] (self=0x6b24900, _cmd=0x3734888) at 
Controller.m:1937
#6  0x037264f4 in -[JEPController returnInfoOnMainThread] (self=0x6b24900, _cmd=0x3734870) at 
Controller.m:1950
#7  0x90a1af48 in __NSFireMainThreadPerform ()
#8  0x901e4664 in __CFRunLoopPerformPerform ()
#9  0x90193e18 in __CFRunLoopDoSources0 ()
#10 0x901915f0 in __CFRunLoopRun ()
#11 0x90195f1c in CFRunLoopRunSpecific ()
#12 0x927d648c in RunCurrentEventLoopInMode ()
#13 0x927d9440 in GetNextEventMatchingMask ()
#14 0x927ed01c in WNEInternal ()
#15 0x927fdd34 in WaitNextEvent ()
#16 0x00212e28 in nsMacMessagePump::GetEvent(EventRecord&) ()
#17 0x00212d0c in nsMacMessagePump::DoMessagePump() ()
#18 0x001f9024 in nsAppShell::Run() ()
#19 0x00849e74 in main1(int, char**, nsISupports*, nsXREAppData const&) ()
#20 0x0084a5e0 in xre_main(int, char**, nsXREAppData const&) ()
#21 0x00009850 in main ()
#22 0x000094e4 in _start (argc=2, argv=0xbffffeb4, envp=0xbffffec0) at /SourceCache/Csu/Csu-46/
crt.c:267
#23 0x00009358 in start ()
(gdb) 

    
    

    
  
(In response to comment #129)

> I have done quite a bit of testing with home-grown applets, and I
> find the results very impressive: our application is overall usable
> already, which wasn't obvious.

I'm very glad to hear it!  My own tests haven't got much farther than
the demo applets that come with the JDK and others that are available
on (or on links from) Sun's applets page
(http://java.sun.com/applets).  Making the basic JVM functionality
available (i.e. ensuring that the demo applets worked) took a _lot_ of
time and effort.  But I've assumed that once the basic problems were
solved, the effort needed would trail off -- which seems to be true.

> I can report on two minors bugs that I have seen, and I believed
> have already been singled out:
> - cropping of the applet graphics: we open new html windows with new
> applets embedded inside. sometimes the new page doesn't open with
> the right size (to be investigated on our side) and crops the
> applet. Then even if I resize the browser window, the cropped part
> is never refreshed, it remains cropped even for new items drawn in
> that part.

I don't believe this has been reported yet, though I've seen it myself
(with the NOAA's radar looping applets, of which one example (cited
above) is http://www.crh.noaa.gov/radar/loop/DS.p19r0/si.klot.shtml).
It's not the same as the text of the www.java.com's test applet being
cut off on the left (http://www.java.com/en/download/help/testvm.jsp),
which (as was pointed out in comment #96) seems to be a layout problem
due to the font used being unexpectedly large.  It may, hoever, be
related to the overwritten lines problem with illustrated in "Picture
3" and described in comment #92.

I suspect that this (like the font size issue) is ultimately a problem
with Apple's JVM.  I might be able to use the Java Embedding Plugin to
work around it -- indeed, if Apple doesn't fix the problem themselves
I'll be forced at least to try.  But right now problems that are
specific to the Java Embedding Plugin are my highest priority.

> - mouse clicks only result in beeps in a dialog with a combo-box and
> OK/dismiss buttons. It is impossible to make a choice, and the
> dialog can only be dismissed with the "close" widget (red button)
> once a mouse click has been made in it.  However, I noticed that if
> I browse the combo-box with the keyboard arrow-keys and make my
> choice with the return key, I can work through it perfectly. Would
> get tricky though if the dialog had more sophisticated inputs.

I won't be able to understand this problem until I've seen an example.

By the way, I looked at your company's site (http://www.sibio.net) but
couldn't find any examples of your applets.  I'd very much like to see
examples, particularly of the two problems you've just described.
Could you post some URLs here, or (if need be) send them to me
privately?  (By the way, I can read some French (with the help of a
dictionary), so the examples needn't be in English.)

    
  
Flags: blocking1.8a? → blocking1.8a-

    
  
URL: http://developer.apple.com/cgi-bin/se... → http://javaplugin.sourceforge.net/
Summary: Support Java 1.4.1 applets, JavaPluginCocoa.bundle → Support Java 1.4.x applets, JavaPluginCocoa.bundle

    
    

    
  
Hi All,

After further testing, I have found three more problems:

1) It seems to me that the Java Embedding Plug-in launches a JVM without caring
for the advanced options entered in the JPI Control Panel. Below is how I came
to this conclusion, however it may be more complicated than that, because it
involves another (known) bug of Apple's JPI.

It all started with Radar N°3198581. This bug was originally reported by my
company and others: the JPI fails to store self-signed applet certificates in
the Keychain, therefore the code is deemed unsigned (1.4.1 introduced the
"improvement" of centralizing Java certificates in the OS X Keychain). This made
our software unusable (all our applets are signed to perform extended network
and file operations).

Apple came with a workaround for the bug, involving an undocumented option for
the JPI to disable Apple "improvements" and revert to Sun's code for handling
signed applets.

Later, Apple updated the Java distribution and closed the bug quite hastily:
although the update works without tricks on many machines, it still shows up
repeatedly on many others (including some Panther/1.4.2, and including almost
every users' Keychain that was earlier the victim of the original bug, that is
most of our customers).

Therefore the trick is still needed. Here it is:
In the Java 1.4.x Plugin Settings (located in /Applications/Utilities/Java/),
go to the "Advanced" tab and enter the following runtime parameter :
    -Dapple.keychain.useJavaKeystore=true

However, even with the runtime parameter correctly set, there is no way to store
the applet certificate permanently (or have it retrieved from the keystore where
Safari previously put it, by the way). The behavior is exactly that of Safari
without the runtime parameter (you can run the code as signed if you click on
"trust only this time" when asked upon first loading, this way no attempt is
made to store the certificate on file for later use). That is what led me to
believe that JavaEmbeddingPlugin doesn't pay attention to the JPI settings (but
it could be more complicated since it's a large picture).

2) (minor) Browser menus often seem disabled after an applet has been launched:
only the leftmost menu pulls, the one with "Quit..." (seen in mozilla-firebird
1.4a, mozilla 1.3, mozilla 1.6, all under 10.2.8). Those menu items that remain
accessible do work.

3) (minor) Sometimes when quitting the browser after using an applet, the
browser remains stuck in the progress of quitting (seen in mozilla 1.3).

    
    

    
  
> 1) It seems to me that the Java Embedding Plug-in launches a JVM
> without caring for the advanced options entered in the JPI Control
> Panel.

You're right, it doesn't.  This is something I overlooked.  I'll fix
it, hopefully in the next version.

(The next version is coming pretty soon.  I've already made a bunch of
other fixes.)

> 2) (minor) Browser menus often seem disabled after an applet has been
> launched: only the leftmost menu pulls, the one with "Quit..."
> (seen in mozilla-firebird 1.4a, mozilla 1.3, mozilla 1.6, all under
> 10.2.8). Those menu items that remain accessible do work.

This sounds like what used to always happen (before I wrote my fixes
in stopModal_AWTCW() of Handlers.m) after you'd dismissed/closed a
Java-initiated modal dialog.  (All of the JVM's security dialogs are
modal.)  Could Java-initiated modal dialogs or windows be involved?
If they are, I'll need to extend my fixes.  (Though before I can do
that, I will of course need to be able to reproduce the problem
myself.)

> 3) (minor) Sometimes when quitting the browser after using an applet,
> the browser remains stuck in the progress of quitting (seen in
> mozilla 1.3).

I haven't tested on Mozilla 1.3.  Nor am I likely to.  But even on
more recent versions of Mozilla, Firefox and Camino I'm seeing
occasional freezes, seemingly at random times.  I'm always able to use
gdb to look at the frozen process (it never crashes badly enough to
make that impossible).  When I do, thread 1 is usually stuck in
drawRect_AWT() of Handlers.m.  This is probably due to one or more
Apple bugs, but I'm trying to find a workaround.



    
    

    
  
Firstly thanks for your time and effort in making Java happen on the Mac!

Heres my problem: LiveConnect doesn't appear to work using Java 1.4.2, Firefox 
0.8 (or Camino 0.7), and JEP 0.8.1. (Works correctly under Safari). The applet 
loads correctly, but when I invoke LiveConnect, a call to:

JSObject win = JSObject.getWindow(this);

fails by returning a null reference. Any ideas?

    
    

    
  
(In response to comment #134)

> Firstly thanks for your time and effort in making Java happen on the
> Mac!

You're quite welcome!

> Heres my problem:  LiveConnect doesn't appear to work using Java
> 1.4.2, Firefox 0.8 (or Camino 0.7), and JEP 0.8.1. (Works correctly
> under Safari). The applet loads correctly, but when I invoke
> LiveConnect, a call to:
>
> JSObject win = JSObject.getWindow(this);
>
> fails by returning a null reference. Any ideas?

To the very limited extent that I've tested it, LiveConnect works fine
for me ... which is to say that I've have no problems with the
following URL :-)

http://www.simonstl.com/dynhtml/update/code/chap6/lc1.html

Does this URL also work for you?

If it does, please put your applet (or a test case) up online where I
can get at it.  Otherwise there's not much I can do.

By the way, are you importing the JSObject class from its traditional
location (netscape.javascript.*) or from some other place (such as
apple.applet.*)?



    
    

    
  
The URL in comment 135 throws an exception for me in Camino 20040607:

java.lang.UnsatisfiedLinkError: getProxyConfigURL

The URL also deactivated the Camino menus, see bug 168549.

This is behind a company squid proxy cache and I'm running Java 1.4.2 Update 1
DP2.  This is the only Java that I have any luck running secure applets through
the proxy, even with Safari.

    
    

    
  
(In response to comment #136)

That URL works fine for me in Camino 20040607 or 0.8b on OS X 10.3.3
with Java 1.4.2, using Java Embedding Plugin 0.8.1.

I haven't yet tested on Java 1.4.2 Update 1 (either DP1, which I was
unable to install, or DP2, which I haven't yet tried to install).  If
the problem's in Update 1, I'll try to fix it when I get around to
testing on Update 1 (which should be fairly soon).  If the problem's
due to your "squid proxy cache", I'm not sure I'll ever be able to fix
it :-)



    
    

    
  
I installed today the Java Embedding Plugin cause I needed Java 1.4 to make
something work. When trying to load the Java Applet, the brwser crashed. I
tryied it in Netscape, and it crashes too. It doesn't say it had an error or
not, it closes and doesn't say anything. This happened while trying to see the
new 3D Live in managerzone (www.managerzone.com). You may not see what I tell
you if you don't have an acount there, but do you know what the problem might
be? Thanks 

    
    

    
  
(In response to comment #138)

There's a Live 3D demo (in the upper left part of the home page)
that's accessible to non-members, on which I'm able to reproduce
exactly what you describe.  But it doesn't seem to be a crash (there's
no record of one in ~/Library/Logs/CrashReporter, and nothing unusual
in the system log).  And it also happens with Safari.  (I haven't yet
tried the demo on other platforms.)

The Live 3D applet is new ... and I suspect it's just buggy.



    
    

    
  
I updated to Firefox 0.9 and the Java 1.4.2 Update 1 Developer Preview 2.

When I try to launch an applet I am now getting:

java.lang.UnsatisfiedLinkError: getProxyConfigURL
	at sun.plugin.net.proxy.MacOSXProxyConfig.getProxyConfigURL(Native Method)
	at sun.plugin.net.proxy.MacOSXProxyConfig.getBrowserProxyInfo(MacOSXProxyConfig.java:30)
	at sun.plugin.net.proxy.PluginProxyManager.reset(PluginProxyManager.java:108)
	at sun.plugin.AppletViewer.initEnvironment(AppletViewer.java:564)
	at jep.MyJavaRunTime.initJavaRunTime(MyJavaRunTime.java:20)
	at jep.AppletHolderFactory.initProperties(AppletHolderFactory.java:131)
	at jep.AppletHolderFactory.createAppletHolder(AppletHolderFactory.java:51)

    
    

    
  
(In response to comment #140)

The same error was reported in comment #136 above by someone who also
has Java 1.4.2 Update 1 DP2 installed.  A different error was reported
in comment #117 by someone using Java 1.4.2 Update 1 DP1.  (It was
also reported in comment #87, though the reporter didn't say whether
or not he's using Java 1.4.2 Update 1.)

I still haven't had a chance to test on Java 1.4.2 Update 1 (either
DP1 or DP2), but it looks likely that Update 1 made some changes that
broke the Java Embedding Plugin.  In version 0.8.1 I managed to fix
yet another Update 1 problem (reported in comment #72) without ever
having installed Update 1.  DP1 wouldn't install on my system (a
dual-CPU G4 running OS X 10.3.3), so I'm a little worried whether I'll
be able to install DP2.  But assuming that I can, it should be
relatively straightforward to get the Java Embedding Plugin working
with Java 1.4.2 Update 1.

So, to sum it up, the Java Embedding Plugin doesn't yet work with Java
1.4.2 Update 1.  I've accumulated a _lot_ of fixes for other problems,
which I'll include in a version 0.8.2 that I hope to release next
week.  That version still won't work with Java 1.4.2 Update 1.  But if
things go well, sometime in the next few weeks I should be able to
release a version 0.8.3 that _does_ support at least the current
release of Java 1.4.2 Update 1.



    
    

    
  
Version 0.8.2 of my Java Embedding Plugin is out:

http://javaplugin.sourceforge.net/

A lot of the problems you reported have been addressed, and mostly (I
hope) solved.  Please let us all know your results.

Two problems I _haven't_ yet addressed:

1. The Java Embedding Plugin doesn't yet work with Java 1.4.2 Update 1.

2. The first problem reported in comment #132 -- the Java Embedding
   Plugin doesn't pay attention to the "Java Plugin Settings"
   program's "Java Runtime Parameters".

I hope to fix both of these in the next few weeks.



    
    

    
  
Steven,

Looking good! Solved all the problems I was having before. Coupled with the new
releases (Mozilla 1.7, Firefox 0.9, and especially Camino 0.8), the Mac Mozilla
family is in real good shape now thanks to your hard work. A suggestion: get
this thing posted on Versiontracker if possible. Many comments on lack of java
support when Mac Mozilla browsers get released, people need to be made aware of
this plugin's existence.

    
    

    
  
Is this stable enough to try to request that it get added to the Seamonkey 1.8
trunk?

    
    

    
  
(In response to comment #143)

> Looking good! Solved all the problems I was having before.

Wonderful!  Glad to hear it.

> A suggestion: get this thing posted on Versiontracker if
> possible. Many comments on lack of java support when Mac Mozilla
> browsers get released, people need to be made aware of this plugin's
> existence.

Thanks for the suggestion (I'll remember it for later) ... but I'm not
quite ready to open the floodgates :-)  Before that happens, I'd really
like to get the JEP working with Java 1.4.2 Update 1.

And I'd like to take a crack at solving the "flicker" problem (#1 in
my KnownProblems.txt).  I know it's not a show-stopper.  But even I
find it annoying ... and after all the JEP is a Mac program, which has
_got_ to be "pretty" :-)



    
    

    
  
(In response to comment #144)

It may be "stable" enough (in terms of how seldom it crashes or
hangs).  But it's not quite ready for really major exposure (see my
comment #145 above).

On the other hand, I don't really understand the implications of the
JEP getting added to the Seamonkey 1.8 trunk.  On the assumption that
I _am_ able to get it working with Java 1.4.2 Update 1, maybe now's a
good time to start the process.

Given the "unauthorized" nature of this project, though, I can't be
sure of making the JEP compatible with Java 1.4.2 Update 1 until I
actually do it.



    
    

    
  
Here's a bug report on my own program :-)

Every so often I Google "Java Embedding Plugin" to see what people
might have to say about it.  Just now I found a Dutch site (MacOSX.nl)
with an article on the JEP.

http://www.macosx.nl/?p=showarticle&art_id=1514

I can't read Dutch, but toward the end it seems to talk about a
problem with LiveConnect, and it links (by an intermediate link) to a
Mozilla page full of LiveConnect tests.

http://www.mozilla.org/quality/browser/front-end/testcases/oji/liveconnecttest.html

I wish I'd known about these!

With JEP 0.8.2, every single test hangs Mozilla 1.7 on Java 1.4.1 and
Mac OS X 1.2.8 :-(  After having used gdb to do a "thread apply all bt"
on a couple of the hung processes, my hunch is that this is a bug in
the MRJ Plugin.

I'll be working on it.



    
    

    
  
You can use the Babelfish (http://babelfish.altavista.com) to translate from
Dutch to English. The translation is not perfect, but it will help.

Type the URL into the lower of the two boxes (the large one is for translating
straight text) and set languages to "Dutch to English".

    
    

    
  
Thanks!  (Google can't translate from Dutch, and I'd forgotten about
the Babelfish.)  The English translation is _slightly_ more
intelligible than no translation at all -- the author actually seems
to be saying that LiveConnect works (which it might for the bank site
he also mentions).  But I know from my own experience that the Mozilla
LiveConnect tests all fail miserably.

I guess the problem is that if the original contains even a little bit
of irony or sarcasm or indirection, machine translations tend to
produce gibberish.

PS:  What is a "smaakje", anyway?  At first I guessed that "met een
smaakje" means "with a smile" ... but that doesn't seem to be right.
Maybe someone who speaks Dutch and English can let us know :-)



    
    

    
  
I'm sorry to report that with the new version using Mozilla 1.7 final I'm still
experiencing the same issue reported in comment #69. I disabled all my other
plugins to no avail. Please let me know what I can help.

    
    

    
  
I speak a bit of Dutch, but not well enough to translate that site easily. I'll
try to have a go at it tonight, though.

As far as the site title goes, "smaak" means flavour or taste, especially in a
good way. Adding "-je" to the end is a diminutive, a bit like adding "y" to the
end of a noun in English, but sometimes it can change the meaning in subtle
ways. So I think the site tag means something like "Apple news with added flavour".

    
    

    
  
(In response to commment #151)

Thanks for anything you can come up with.  Don't go to too much
trouble, though.

> So I think the site tag means something like "Apple news with added
> flavour".

I was hoping it didn't mean "Apple News With a Smiley" :-)



    
    

    
  
(In response to comment #150)

Ah ... the evil "keyboard problem" rears its head again :-)

With version 0.8.2 I made some pretty fundamental changes to the code
that handles keyboard and mouse events.  So I'm actually a little
surprised the problem hasn't gone away. ... No, I'm not really that
naive.  "Dismayed" is more accurate :-(

In addition to these changes, I made a few aimed directly at the
"keyboard problem".  I didn't mention them because I didn't dare hope
for much.  I was able to make them because I actually experienced
something like what you described a couple of times myself -- it was
always when I typed characters in the "URL box" (I don't know its
official name) after an applet had begun loading, but before it had
actually started (before the Applet.start() command had been issued).
The NOAA radar-looping applets have a particularly long delay between
when they begin loading and when they actually "start" ("AniS --
Revision: 2.28" or something like that appears in the Java console
when an NOAA radar-looping applet actually "starts").

Could this be what's been happening to you?  If I remember right, you
don't _always_ experience the "keyboard problem"?

In any case, until I get significant new information, there's no way
I'm going to be able to solve this problem.  I haven't yet heard from
anyone else about it.  If any of the rest of your are experiencing it,
please let all of us know (or just me if you'd prefer).  Be sure to be
as detailed and precise as possible.

The more good reports I get, the more likely I'll be able to winnow
out the actual cause from all the other, extraneous factors.



    
    

    
  
(Following up comment #153)

Thinking over the "keyboard problem" I realized that I've never
received from you (nor asked for) detailed, step-by-step instructions
for recreating the problem.  If it's possible to provide them, that
would be very helpful.  They need to trigger the problem at least 50%
of the time.  If you can provide several different sets of
instructions that meet these criteria, that would be even better.



    
    

    
  
(In reply to comment #154)

See comment #69 and comment #111 for instructions I provided previously. To add
more clarification, when I say "switch to another app", I do it using keyboard
shortcuts only (Apple-Tab). I don't remember whether it happens when I use the
mouse. Also, any applet seems to cause the issue. I've been using the jvm test
applet most times. Closing the tab with the applet is not required. Neither is
switching to another tab. The issue happens regardless of any of those things.

    
    

    
  
(In response to comment #155)

> To add more clarification, when I say "switch to another app", I do
> it using keyboard shortcuts only (Apple-Tab).

_This_ was the key, the "significant new information" I was looking
for.  Now I'm able to consistently reproduce the problem, though not
quite exactly as you describe.

Sigh.

I still can't promise that I'll be able to fix the problem ... but now
I stand a much better chance than I did before.

And I found another way to reproduce it (which despite the
"keyboard-problem"-specific changes I described in comment #153, still
"works"):  Open at least two tabs in a window.  Load an applet in one
of them (this must be the first applet you've loaded in this window,
in any of the tabs).  Close the tab before the applet has finished
loading (i.e. _just_ after the JVM has started, and _well_ before the
Applet.start() command has been issued).



    
    

    
  
Steven, I presume you've seen the Mac Java Community site?
http://community.java.net/mac/
There are a number of projects listed there. Maybe that'd be a good place to
publicize your project, too.

    
    

    
  
(Following up comment #147)

Here's an update on the JEP's problems with Mozilla.org's LiveConnect
test pages:

The hangs (mostly) didn't happen with Mozilla 1.6 and family ... but
always happen with Mozilla 1.7 and family unless you've previously
loaded an applet into at least one of the running browser's windows.
Their cause is ultimately a bug (or design flaw) in how Apple's JVM's
AWT libraries (such as libawt.jnilib) are loaded -- if you start the
JVM and then try to load the AWT libraries in the same thread before
the JVM has finished initializing, the browser will hang in
libawt.jnilib at JNI_OnLoad().

All released versions of the JEP have a workaround for this bug if the
browser is loading an applet.  But most of the tests on the
LiveConnect test pages use LiveConnect (via JavaScript) without ever
loading an applet.

I've now created another workaround to deal with the case of using
Java without loading an applet.  I need to use it for a while to make
sure that it doesn't cause problems of its own.  With luck I should be
able to include it in the next version of the JEP.



    
    

    
  
I installed the java embedded plug in but now firefox 0.9 crashes every time.  I removed the MRJPlugin 
and the crashes stopped but of course I'm back to java 1.3.1.

Any ideas on what I can do to get this fixed?

Thanks
Matt

    
    

    
  
(In response to comment #159)

Before I can have any idea what's going on, I need some details.
Like:

1) Your OS X version
2) Your Java version (results of "java -version")
3) The URL for a page that triggers the crash
4) The contents of your ~/Library/Logs/Java Console.log file after the
   crash (assuming you haven't changed the Plugin Control Panel's
   console setting from the default ("Do not start console") to "Show
   console").
5) Whether or not Safari also crashes on the same URL(s).
6) Whether or not lines have been added after the crash to
   ~/Library/Logs/CrashReporter/firefox-bin.crash.log.  (If not, then
   what you've experienced wasn't a crash.)  If lines were actually
   added, don't post them as a comment -- they're likely to be several
   hundred of them.  Instead put the relevant lines in a separate file
   and "Create a New Attachment".



    
    

    
  
(In reply to comment #154)
> (Following up comment #153)
> 
> Thinking over the "keyboard problem" I realized that I've never
> received from you (nor asked for) detailed, step-by-step instructions
> for recreating the problem.  If it's possible to provide them, that
> would be very helpful.  They need to trigger the problem at least 50%
> of the time.  If you can provide several different sets of
> instructions that meet these criteria, that would be even better.
> 
> 

Steve,

there's good and bad news with JavaEmbeddingPlugin 0.8.2.

1. The good news is, that Mozilla 1.7 does not crash anymore when selecting Live
Coverage at http://www.europeantour.com/home/.

2. The bad news is, that there is some sort of keyboard problem. After visiting
http://www.pannonia-ring.com/index.php?popup=0&menu0=7&menu1=&PHPSESSID=7762b5738d88a3f898f9da93631a797a
and an unsuccessfull try to see the video on the racetrack (click on any of the
numbers on the map, these are .avi that cannot be handled by QuickTime Player)
the keyboard changes to applying "double-action". e.g. if you have several tabs
open and type Apple-w it will not only close one tab but two! Furthermore there
is a warning-tone whenever you type Apple-r in one of the tabs. Quitting Mozilla
an relaunch solves this issue. 

    
    

    
  
(In reply to comment #161)
> (In reply to comment #154)
> > (Following up comment #153)
> > 
> > Thinking over the "keyboard problem" I realized that I've never
> > received from you (nor asked for) detailed, step-by-step instructions
> > for recreating the problem.  If it's possible to provide them, that
> > would be very helpful.  They need to trigger the problem at least 50%
> > of the time.  If you can provide several different sets of
> > instructions that meet these criteria, that would be even better.
> > 
> > 
> 
> Steve,
> 
> there's good and bad news with JavaEmbeddingPlugin 0.8.2.
> 
> 1. The good news is, that Mozilla 1.7 does not crash anymore when selecting Live
> Coverage at http://www.europeantour.com/home/.
> 
> 2. The bad news is, that there is some sort of keyboard problem. After visiting
>
http://www.pannonia-ring.com/index.php?popup=0&menu0=7&menu1=&PHPSESSID=7762b5738d88a3f898f9da93631a797a
> and an unsuccessfull try to see the video on the racetrack (click on any of the
> numbers on the map, these are .avi that cannot be handled by QuickTime Player)
> the keyboard changes to applying "double-action". e.g. if you have several tabs
> open and type Apple-w it will not only close one tab but two! Furthermore there
> is a warning-tone whenever you type Apple-r in one of the tabs. Quitting Mozilla
> an relaunch solves this issue. 

P.S. I just found out that it also happens if you open the above page in Safari
and then switch back to Mozilla: Typing Apple-w closes two tabs instead of one.

    
    

    
  
(In response to comments #161 and #162)

> 2. The bad news is, that there is some sort of keyboard
> problem. After visiting
>
http://www.pannonia-ring.com/index.php?popup=0&menu0=7&menu1=&PHPSESSID=7762b5738d88a3f898f9da93631a797a
> and an unsuccessfull try to see the video on the racetrack (click on
> any of the numbers on the map, these are .avi that cannot be handled
> by QuickTime Player) the keyboard changes to applying
> "double-action". e.g. if you have several tabs open and type Apple-w
> it will not only close one tab but two! Furthermore there is a
> warning-tone whenever you type Apple-r in one of the tabs. Quitting
> Mozilla an relaunch solves this issue.

> P.S. I just found out that it also happens if you open the above
> page in Safari and then switch back to Mozilla: Typing Apple-w
> closes two tabs instead of one.

I'm unable to reproduce either of these problems, on OS X 1.2.8 with
Java 1.4.1 or on OS X 10.3.4 with Java 1.4.2.  In all cases my browser
was Mozilla 1.7.

However, I already know I have unsolved keyboard problems (see comment
#156 and above).  I will do my best to fix them, but so far they have
been very tricky.

> 1. The good news is, that Mozilla 1.7 does not crash anymore when
> selecting Live Coverage at http://www.europeantour.com/home/.

Are you talking about "Live Java Scoring" (which is available on the
"Scores" page that you can open from the main menu)?  Out of
curiosity, I tried this in OS X 10.2.8 (Java 1.4.1) and OS X 10.3.4
(Java 1.4.2) with the JEP and MRJ Plugin JEP from version 0.8.1 -- no
crash.  (Again the browser was Mozilla 1.7.)  Maybe they've changed
the applet.  Or maybe you're referring to a different applet.

I was unaware of the European Tour site or of any applets on it ... so
JEP 0.8.2 contains no specific fixes for any problems with them :-)



    
    

    
  
> I was unaware of the European Tour site or of any applets on it ... so
> JEP 0.8.2 contains no specific fixes for any problems with them :-)
> 
> 

Hi Steven,

I reported this here: http://bugzilla.mozilla.org/show_bug.cgi?id=219676

    
    

    
  
I see a drawing issue with this page:
  http://www.jensign.com/JavaScience/www/testsscert/

the box draws off the edge of the page.   Safari is OK, if I remove the JavaEmbeddingPlugin it's OK, 
though slightly different than Safari.

The page test says it specifies version 1.3, but ignore that as the contents say that it's really using 1.4.

OS X.3.4
java version "1.4.2_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-117.1)
Java HotSpot(TM) Client VM (build 1.4.2-34, mixed mode)

BTW, this is a signed applet that functions properly, with no java console errors.

    
    

    
  
I'm having mixed results with LiveConnect.

This one works for me:
  http://information.overlaid.com/stable/weasel/installation/liveconnect_in.html
its companion:
  http://information.overlaid.com/stable/weasel/installation/liveconnect_in.html
is more interesting.

If it's the first thing loaded it stays at 'initializing'.  If it's reloaded, it works as expected.  If it's loaded 
after liveconnect_in.html it causes a hang.  (beachball of death)

This one usually works, though I've seen it hang if it's not run first:
  http://www.simonstl.com/dynhtml/update/code/chap6/lc1.html
This one is always hanging, after the alert sheet comes down:
  http://www.simonstl.com/dynhtml/update/code/chap6/lc2.html

There may be some variation on the order of running things, but if you take these 4 URL's and load 
them in different orders you're just about guaranteed to see some hangs.  I don't think I've discerned 
the causitive pattern.

    
    

    
  
Sorry, I mispasted in the previous comment.  The "companion page" URL should be:
  http://information.overlaid.com/stable/weasel/installation/liveconnect_out.html

These pages are all OK in Safari and with your new MRJPlugin, sans JavaEmbeddingPlugin.

    
    

    
  
(In reply to comment #165)

I see more or less what you describe ... but the applet displays very
differently even when it manages to display "correctly" -- i.e. even
when all the necessary controls and text are present on the screen.

Nothing ever displays outside of the applet's box.  But in the JEP the
contents of the box are quite a bit larger both to the left (where 
some of the text is cut off) and to the right (where the vertical
scroll bar is completely missing).  In Safari nothing is cut off to
the left, but the vertical scroll bar is partly cut off to the right
(though it's still usable).  In Java 1.3.1 (with or without my MRJ
Plugin JEP) the font is very much smaller, and there are large blank
margins on the left, right and bottom.

I'm not sure what, if anything, I can do about this.  But I'll add it
to my list :-)

From all the variation in the way it displays, though, I do get get
feeling that there's something wrong with the applet.



    
    

    
  
(In reply to comment #166 and comment #167)

I'm able to reproduce pretty much exactly what you describe, on OS X
10.2.8 with Java 1.4.1 and OS X 10.3.4 with Java 1.4.2, using either
Mozilla 1.6 or 1.7.  It doesn't seem to be related to the problem I
describe in comment #158 and above.

LiveConnect has been a pain and a half ... but it's possible that the
crashes (at least) are due to a bug in the MRJ Plugin.  (I've been
seeing crashes in CSecureEnv::sendMessageToJava(), which seems to be
used exclusively for JavaScript to Java communication.)

Once again I'll add the problem to my list.  But this one's a bit
closer to the top -- both because it's more serious and because I have
an inkling about how to solve it.

> These pages are all OK in Safari and with your new MRJPlugin, sans
> JavaEmbeddingPlugin.

If you remove my JEP but keep my MRJ Plugin JEP, you'll (of course) be
using Java 1.3.1.  The results I get with this configuration are
better, but still not perfect:

liveconnect_out.html "fails" on the first attempt, though it
"succeeds" if you reload it.  And it only hangs some of the time :-)

For me lc2.html always hangs.



    
  
Blocks: 163468

    
    

    
  
Steven,

Is it safe to install Apple's Java update (1.4.2 Update 1) available today, or
does this break your plug-in?

    
    

    
  
(In reply to comment #170)
> Steven,
> 
> Is it safe to install Apple's Java update (1.4.2 Update 1) available today, or
> does this break your plug-in?

Per the readme and my experience it appearently does not work, "yet".

    
    

    
  
(In reply to comment #170 and comment #171)

I'm afraid Apple's release of Java 1.4.2 Update 1 caught me by
surprise.  Not that it hasn't been in beta for a _long_ time ... I
just thought it wouldn't be released for longer still :-(

What's more, I've been on vacation for the last week.

Over the last couple of days I've got the basics working, but there
are still significant problems clipping applets that (like the NOAA
weather applets) update their display dynamically.  I hope I can solve
the clipping problems quickly.  But even if I don't, I intend to
release _something_ by the end of the week.

I assume that, for most people, an imperfect Java Embedding Plugin
would be better than nothing at all :-)



    
    

    
  
I'm sure there are others like myself who've been holding off on installing the
Apple Java update until we hear something from you, not to put you under any
additional pressure :-)

Take your time and get it right, we've waited this long... BTW, welcome home!

    
  
Alias: osxjava1.4

    
    

    
  
Version 0.8.3 of the Java Embedding Plugin is up on SourceForge:

http://javaplugin.sourceforge.net/

1) It now supports Java 1.4.2 Update 1!

I figured out the clipping problems I was having.  But I so wanted to
get the new version out quickly that I didn't test it on OS X 10.3.3
or 10.3.4, or with Java 1.4.2 "plain" (only on OS X 10.2.8 with Java
1.4.1 and OS X 10.3.5 with Java 1.4.2 Update 1).  I don't anticipate
any trouble with Java 1.4.2 "plain", and people who need to stick with
that Java version can go back to JEP 0.8.2 if they have to.

If some of you haven't yet installed Java 1.4.2 Update 1, please try
JEP 0.8.3 with Java 1.4.2 "plain" before you download Update 1 -- and
let us know if you have trouble.

Version 0.8.3 also has some other fixes that were ready to go before
the Update 1 crisis, notably:

2) Support for using Apple's Java Control Panel to specify "runtime
   parameters".

3) Fixes for the "keyboard problem" to which so many of the messages
   here have been devoted (comment #156 and above).  I _hope_ that the
   problem is mostly resolved -- though I'm pretty sure it isn't gone
   completely.

4) Fixes for several LiveConnect problems, including the one I
   described in comment #158 and the ones reported by Bill McGonigle
   in comment #166 and comment #167.

   On my way to solving these problems, I noticed that the
   "liveconnect_out" applet has problems of its own, which I didn't so
   much resolve as work around.  Even on Windows (in Mozilla 1.7.2),
   reloading it several times causes some browser features to stop
   working, though (unlike on OS X) the main thread doesn't hang.  My
   "fix" for this applet on OS X only "works" at the cost of leaving
   zombie threads -- though this is an improvement over hanging the
   main thread, and is (probably) worth doing as a general precaution.



    
    

    
  
In limited testing on OSX 10.3.5 and Java 1.4.2 ("plain" java), all seems well.
NOAA Weather applets, Time.gov, Dancing Duke at Java.com, and the java test at
http://gemal.dk/browserspy/java.html all work well. Been holding of on the java
update until this was ready. Thanks Steven. As always... nice job!

    
    

    
  
Top job, Steven!

Is there any chance of mentioning this problem and/or this plugin in the README
file for Mozilla on the Mac? Drivers, module owners do you have an opinion?

    
    

    
  
(CCing Asa)

Asa: any chance to mention the bug & the plugin in the release notes?

    
    

    
  
Thanks for the good workd Steven. I can confirm that the bulk of the keyboard
issues I was seeing no longer exist.

However, I am still seeing a trace of the issue. To reproduce, click one of the
links to an applet listed in this bug (I used Sun's testvm applet). After
clicking the link, let the page load without clicking anywhere else. Then use
the down arrow key. The machine beeps. Ordinary Mozilla behavior is to simply do
nothing. Simply clicking in the page once allows the browser to work as expected
from that perspective.

I am seeing a new (I think) issue. After I open an applet, some keystroke
commands are executing twice within that browser window instance. For instance,
command-T and command-W open or close two tabs rather than one.

    
  
Keywords: relnote
Whiteboard: plugin solution: http://javaplugin.sourceforge.net/

    
    

    
  
(In reply to comment #178)

> I am seeing a new (I think) issue. After I open an applet, some keystroke
> commands are executing twice within that browser window instance. For instance,
> command-T and command-W open or close two tabs rather than one.

I've seen this issue already with 0.8.2 (could have been under 10.3.4 or under
10.3.5 plus 1.4.2 Update 1, I can't remember). 



    
    

    
  
(In reply to comment #176)
> Top job, Steven!
absolutely! works great for me!

> Is there any chance of mentioning this problem and/or this plugin in the README
> file for Mozilla on the Mac? Drivers, module owners do you have an opinion?
thats right. the plugin - although still in beta status - should be published
and must be mentioned on the mozilla and firefox download pages. hardly any user
experiencing problems with java will check bugzilla and find the plug-in.

    
    

    
  
So you guys have rendered this bug report useless: it has turned into a support
forum for the javaplugin SourceForge project. I suggest you use the SourceForge
forums and bug reporting system to discuss issues with that project.
Now to get it somewhat back on topic, where is the source for this plugin and is
it under a Mozilla-compatible license so that we can maybe integrate and ship it
with Mozilla?

    
    

    
  
(In reply to comment #181)

> I suggest you use the SourceForge forums and bug reporting system to
> discuss issues with that project.

In the long term I agree that's what we should do.  But it's been more
or less spontaneously that this bug (197813) has turned into a support
forum for the Java Embedding Plugin, and I think it should stay that
way at least for a while:  This is where people have grown used to
finding the best and latest information.

> Now to get it somewhat back on topic, where is the source for this
> plugin and is it under a Mozilla-compatible license so that we can
> maybe integrate and ship it with Mozilla?

http://javaplugin.sourceforge.net/

The Java Embedding Plugin has a BSD-compatible license.  I'm not sure
what that means for inclusion in Mozilla.  For the time being I'd
prefer that it stay separate (i.e. that it retain its independant
existence as a SourceForget project).  Of course the license terms
allow Mozilla to include it anyway (in effect to fork it) ... but I
don't expect you really want to do that, yet :-)

I am, by the way, the Java Embedding Plugin's author.



    
    

    
  
(In reply to comment #178 and comment #179)

> I am seeing a new (I think) issue. After I open an applet, some
> keystroke commands are executing twice within that browser window
> instance. For instance, command-T and command-W open or close two
> tabs rather than one.

> I've seen this issue already with 0.8.2 (could have been under
> 10.3.4 or under 10.3.5 plus 1.4.2 Update 1, I can't remember).

I've confirmed this with JEP 0.8.2 and 0.8.3 on Mac OS X 10.2.8 with
Java 1.4.1 and OS X 10.3.5 with Java 1.4.2 Update 1 :-(

I'll be looking for a fix.

> However, I am still seeing a trace of the issue. To reproduce, click
> one of the links to an applet listed in this bug (I used Sun's
> testvm applet). After clicking the link, let the page load without
> clicking anywhere else. Then use the down arrow key. The machine
> beeps. Ordinary Mozilla behavior is to simply do nothing. Simply
> clicking in the page once allows the browser to work as expected
> from that perspective.

This I haven't (yet) reproduced.



    
    

    
  
(Following up comment #182)

Peter Van der Becken has repeated to me, in private email, his
objection to our continuing to use bugzilla.mozilla.org as a support
forum for the Java Embedding Plugin (as long as the Java Embedding
Plugin isn't a Mozilla.org project).

Much could be said, on both sides, about the merits of his objection.

But maybe the time has come to switch forums.  What do you think?

In some ways SourceForge is better set up for this purpose.  For
example, here all the bug reports and comments are lumped together
into a single, undifferentiated mass.  Even I find it hard to keep
them all straight.

On SourceForge you have three different options -- online forums, the
"tracker" system and mailing lists (I haven't set up any mailing
lists, but I could if people requested it).  The online forums and
"tracker" let you (at least) separate items by subject line.  The
tracker is also searchable (to a limited extent).

If people have no strong objections, that's what I'm going to
recommend.  I just set the "Bugs" tracker as my "preferred support
mechanism" (previously it was the "Help" forum).

I'll continue to monitor this bug (197183) in bugzilla.mozilla.org,
and continue to respond here to bug reports and comments.  But I'll
always suggest that the reporter's _next_ bug/comment should be sent
to the appropriate SourceForge forum.

What do people think?  Any strong objections?  Please let me know (by
private email if you'd prefer).



    
    

    
  
Well, I certainly hope this bug will be updated when the plugin becomes final.

    
    

    
  
(In reply to comment #185)

I'll still post new version announcements here :-)



    
    

    
  
Well, moving to sourceforge for discussion seems fine to me, as long as anything
that demonstrates movement towards a solution on this bug (including, but not
limited to new version announcements) is posted here.

I am thinking of progress of porting the Sun OJI, changing Mozilla to use Cocoa,
or Apple getting anywhere with documentation. Now each of these is probably a
project that warrants its own (meta)bug report, but I'd still like to know. As
Steven mentioned, this is the place people look for news.

In the mean my bank site is working with Mozilla and I am very happy with the
plugin!

    
    

    
  
(In reply to comment #181)

I completely disagree with Peter Van der Beken's negative comment that, "You
guys have rendered this bug report useless." Mozilla staff have not produced any
tangible solution to the problem. The only working solution we've seen has come
from Steven Michaud, and he was urging users of the plugin to post their
comments and experiences in order to be able to determine existing problems in
the plugin, troubleshoot their causes, and discover solutions. Mozilla users
using Mac OS X would benefit in the end through the plugin, whether it was a
Mozilla-developed plugin or not; as a result, Mozilla staff would see wider
adoption of the browser among those on the OS X platform. Criticizing both users
who sought to make the plugin more reliable and the only party working on a
solution to the bug isn't helpful in resolution of this bug report.

(My disclaimers: I'm not speaking for Steven, only for myself. And, I appreciate
all the work the Mozilla staff does on a daily basis--there just aren't the
resources to fix every problem in the blink of an eye. So, I appreciate help in
resolving Mozilla issues and bugs when they come from outside the organization,
too.)

-- David Lawhon

    
    

    
  
(In response to comment #181)

I don't mind moving it, myself. (Hey, I'm just an appreciative tester!) But on
the flip side, I wouldn't want to encourage obnoxious behavior by appearing to
appease the author of comment #181.



    
    

    
  
(In reply to comment #188)

Correction: I was wrong that the poster of comment #181 is part of the Mozilla
staff. Apologies to the Moz developers for the implication.

-- David

    
    

    
  
(Following up comment #184)

It's been almost a week, and nobody's made any strong objections
(either here or in private email) to moving the routine discussion of
the Java Embedding Plugin to its site on SourceForge.  The number of
"voters" is very small, but among them the majority opinion seems to
be "I'd rather not move, but it's not a real problem if we do".  If
convenience were the only factor, that'd be my opinion, too.  (More or
less:  Though we have all the best information here at our fingertips,
it _is_ incovenient, for us and for those just interested in finding
out the current state of support for Java 1.4.X in Mozilla and family,
to have all the comments lumped together in one undifferentiated
mass.)

But convenience isn't the only factor.  Having the JEP's bug reporting
forum here (or its "support forum" in a broad sense) blurs some lines
that I now realize should be kept very clear.  The Java Embedding
Plugin is a separate project, and I (now) intend for it to remain so
indefinitely (not least because it might get used by other browsers
outside the Mozilla family).  (I haven't changed my mind, exactly.  I
was buried in the technical issues and didn't give the
political/administrative ones much thought.)

It's not that I don't want the Java Embedding Plugin to be integrated
with Mozilla -- I just want it to be done the right way.

I'm already in discussion with Mozilla.org people about including the
changes I've made to the MRJ Plugin in the Mozilla tree (the MRJ
Plugin JEP stuff really is Mozilla-specific, and is a seperate issue
from the Java Embedding Plugin "in the narrow sense").  (Not (yet)
Mozilla staff members, but developers who oversee Mozilla's various
parts, including Peter van der Beken.)

For the Java Embedding Plugin itself, I'm aiming for something like
the arrangement Mozilla.org currently has with the creators of libjpeg
(which like the JEP has a BSD-compatible license) -- integration of a
snapshot.  But I'm getting way ahead of the game.  I don't want the
JEP to be integrated in any fashion until it's out of beta.  The JEP
currently still has a number of significant bugs ... and people keep
finding new ones.  Until all the major bugs are found and squashed (at
least the ones that are easy to find), I don't want the JEP getting
into the hands of tens of thousands of naive users.

When will the Java Embedding Plugin have its first non-beta release?
I don't know.  But how about I wait until the project has gone one
month with no major bugs outstanding and no new ones discovered by
myself or others?



    
    

    
  
(In reply to comment #191)
> (Following up comment #184)
> 
> It's been almost a week, and nobody's made any strong objections
> (either here or in private email) to moving the routine discussion of
> the Java Embedding Plugin to its site on SourceForge.  

I do have one concern. I am afraid that users of Mozilla product will be lost in
the move to Sourceforge. What I mean is that there needs to be a way to keep
Mozilla users updated about releases of the Java plugin. Mozilla users need to
know when the plug in is ready for testing/or released. As many users as
possible should be testing this plugin in Mozilla as it is developed.

Many testers using Mozilla products may not move over to Sourceforge for
testing. At a minimum could this Mozilla bug report be used for major
announcements of the plugin's progress, i.e. need for many users to test or the
final version of the plug in is advailable for download.

I have few objections to this bug moving to sourceforge as long as major
announcements about the bug's prgress is still reported here. The bulk of the
development "chatter" can happen at sourceforge.

    
    

    
  
(In reply to comment #192)

I'll keep posting detailed new version announcements for the JEP here,
each of them ending in something like "bug reports to SourceForge".

And do, please, keep submitting those bug reports.  The JEP's
user-base is still entirely Mozilla/Firefox/Camino users.  The bug
reports you've already posted have been very useful -- just look at
how much the JEP has evolved from its first release (version 0.8.0).

The more reports you submit now (and the harder I work to fix the
bugs), the faster the JEP will get out of beta :-)



    
    

    
  
Bug 162134 is still showing some errors with the current plugin. Not sure if
this needs to be fixed in Mozilla or if the plugin can fix the problems.

FYI, the new plugin is much more well behaved in Tabs than the current Mozilla one.

    
    

    
  
*** Bug 261702 has been marked as a duplicate of this bug. ***

    
    

    
  
I've just released version 0.8.4 of the Java Embedding Plugin:

http://javaplugin.sourceforge.net/

Please try it out!

You can submit bug reports using the JEP project page's "Bugs"
tracker.  The best place for general discussion of the Java Embedding
Plugin (including responses to this message) is probably the "Open
Discussion" forum.

I spent huge amounts of time rewriting (and testing) the keyboard
event and "window cache" handing code for Carbon browsers.  I now get
much better results with applets in tabs on Carbon browsers --
particularly ones that support text-entry (even in non-Western scripts
such as Chinese and Japanese).  I've also dealt with the duplicate
results from certain keyboard shortcuts (discussed in comment #178,
comment #179 and comment #183 above).
 
Applets in tabs still don't work very well in Camino ... but I'm
afraid that's as much a problem with Camino as it is with the JEP.  (I
hope to have time in the future to research how Camino might be
changed to deal with this problem.)

There are also a bunch of other significant bug fixes.

(In reply to comment #194)

I was happy to find that the test URL mentioned in Bug 162134

http://www.mozilla.org/quality/browser/front-end/testcases/oji/test1.html

works perfectly using JEP 0.8.4 and Firefox 1.0PR, though there are
still a few ghost images with Mozilla 1.7.3.



    
    

    
  
Some feedback: This plugin works. I works with the Mozilla Suite 1.8a4 (20040915
)

I am using a B/W G3-350 (more info below).

I tested the plugin at the Java test page:

http://www.java.com/en/download/help/testvm.jsp

I was able to view the dancing Duke logo.


Congratulations. The latest version on your
Your Java configuration is:
           Vendor:           Apple Computer, Inc.
           Version:                      1.4.2_05
      Operating System:         Mac OS X
        OS version:                   10.3.5

Thank you Steven! Thanks for all your hard work!

    
    

    
  
I've just released another new version of the Java Embedding Plugin --
version 0.8.5.

http://javaplugin.sourceforge.net/

Please try it out!

You can submit bug reports using the JEP project page's "Bugs"
tracker.  A good place for general discussion is the "Open Discussion"
forum.

It turns out the keyboard/mouse event and window cache handling code
that I'd spent so much time on for version 0.8.4 wasn't quite done yet
-- in fact it introduced some new bugs.  These have (I think) been
mostly fixed in version 0.8.5.

> I was happy to find that the test URL mentioned in Bug 162134
>
> http://www.mozilla.org/quality/browser/front-end/testcases/oji/test1.html
>
> works perfectly using JEP 0.8.4 and Firefox 1.0PR, though there are
> still a few ghost images with Mozilla 1.7.3.

I'm afraid this was a bit premature :-)

Though it's true that even JEP 0.8.4 showed very few ghosts while
switching between tabs in Firefox, in other respects it didn't do very
well on the "Tags" tests at

http://www.mozilla.org/quality/browser/front-end/testcases/oji/

For JEP 0.8.5 I devoted quite a bit more attention to them --
particularly tests 1 and 2.  The results for test 1 are now close to
perfect (aside from the tab-switching ghosts you still see in
Mozilla).  And JEP 0.8.5 gets much better results with test 2 than did
previous versions, though not as good as for test 1 -- the results
from scrolling the window are pretty good, but resizing the window
tends to make some of the applet copies appear multiple times.  In any
case JEP 0.8.5's results on test 2 are _much_ better than those for
the "Java Applet.plugin".



    
    

    
  
I've just released version 0.8.6 of the Java Embedding Plugin:

http://javaplugin.sourceforge.net/

Submit bug reports using the JEP project page's "Bugs" tracker.  A
good place for general discussion is its "Open Discussion" forum.

I've fixed several more bugs, including a whole class of LiveConnect
bugs in the MRJ Plugin.  I now also get perfect (or close to perfect)
results on the OJI "Tags" tests for everything but tab switching.  (As
I mentioned in comment #196, I was already getting near-perfect
results for tab-switching in Firefox using JEP 0.8.4.  I still am with
JEP 0.8.6.  But not in Mozilla or (especially) Camino.)

http://www.mozilla.org/quality/browser/front-end/testcases/oji/

(As you may have noticed, I am releasing new versions more frequently,
in what I hope is the lead-up to version 1.0.  Keep testing and filing
those bug reports!)



    
    

    
  
One issue with tabs in Camino is that applets will "show through" tabs being on top, but only 
obstructing the view, not drawing or anything. This does not happen in Firefox.

This way, or may not, be related to https://bugzilla.mozilla.org/show_bug.cgi?id=156583

    
    

    
  
(In response to comment #200)

I haven't had time to investigate this problem thoroughly, but I've
seen what you describe.  It seems that (as I say in my
KnownProblems.txt) each applet's (blank) background remains visible in
all the other tabs.

The problem doesn't happen with the Java Embedding Framework and Java
1.3.1, used via either the MRJ Plugin JEP or the "Java Applet.plugin".
The blank background presumably has to be some kind of NSView object.
How the Java Embedding Framework (which doesn't know Cocoa) manages to
deal with it I don't know.  Maybe it _doesn't_, and Camino is playing
some fancy tricks with Carbon event handlers.  I haven't yet spent the
many hours it would take to find this out.

Does someone on this list by any chance know the answer?

(Your idea that this problem is related to Bug 156583 is intriguing.
What I found when I visited the guerillanews.com site mentioned there
doesn't quite match the reporter's description.  I found that a single
frame shows through in all the other tabs, whether or not the
QuickTime movie is playing.  But not when you first create a new tab
... only when you switch away from that (new) tab and then switch
back.  Exactly the same thing happens with the blank applet background
-- which does suggest some kind of relation.  But I don't know enough
about how Camino handles tabs to follow this up.)



    
    

    
  
This same behavior is seen in Mozilla builds and being tracked with Bug 162134.

    
    

    
  
(Following up my own comment #196 and comment #201)

> Applets in tabs still don't work very well in Camino ... but I'm
> afraid that's as much a problem with Camino as it is with the JEP.
> (I hope to have time in the future to research how Camino might be
> changed to deal with this problem.)

I've now looked further into this ... and I've solved the problem (I
think).  Figuring it out wasn't nearly as awful as I'd feared :-)

All I needed was to play a few more tricks with Cocoa browsers like
those I'm already playing with Carbon browsers.  The upshot is that,
using my current version of the Java Embedding Plugin, applets in tabs
now work almost as well in Camino as they do in Firefox (and better
than in Mozilla).  I hope to release this new code in a week or two in
a JEP 0.8.7.

> The blank background presumably has to be some kind of NSView
> object.

It turns out it _is_ an NSView object, but not (as I had expected)
anything created by Camino.  Rather, it's my AppletView object (a
subclass of NSView) being displayed without any contents.  I've now
stopped this from happening if my AppletView object is "invisible".
(I also had to come up with a hack to explicitly stop invisible applet
views from receiving keyboard and mouse input.)

(In response to comment #202)

I tried to use the guerillanews.com "Redux" movie to recreate in both
Camino and Mozilla the problem I'd talked about in my previous
comment.  But the old file is no longer available, and the new file
doesn't trigger the problem in _any_ of the Mozilla family.  The
general problem (of plugins (and not just applets) showing through in
other tabs) is deeper than I first thought :-(



    
    

    
  
Seen over at bug 162134 - anybody have ADC incidents to burn?:

From http://developer.apple.com/java/faq/#anchor4

4: What J2SE version do Java applets run under inside a browser?

Apple's Safari browser only supports Java applets under J2SE 1.4.x. Other
browsers are currently developed to specifically use our 1.3.1 implementation,
and will need to be updated. If you would like to see your favorite browser use
1.4.x on Mac OS X, please contact the vendor and ask them to work with Apple to
adopt the newer version.


    
    

    
  
I've just released version 0.8.7 of the Java Embedding Plugin:

http://javaplugin.sourceforge.net/

Submit bug reports using the JEP project page's "Bugs" tracker.  A
good place for general discussion is its "Open Discussion" forum.

The new version includes a workaround for a bug/design-flaw in Firefox
1.0 that broke the MRJ Plugin, and thereby caused crashes when doing
LiveConnect.  For more information on this issue see:

http://sourceforge.net/tracker/index.php?func=detail&aid=1063222&group_id=107955&atid=649116
https://bugzilla.mozilla.org/show_bug.cgi?id=234169

I've also greatly improved the handling of applets in tabs in Camino
(see comment #200 and comment #201 above), fixed several other bugs,
and made design changes that should allow the Java Embedding Plugin
work with a larger range of internet banking sites.



    
    

    
  
Considering the massive influx of duplicates on bug 162134, most of which are
Java related, and the facts that there seem to be no outstanding issues left at
sourceforge (two of three might already be fixed with the latest release). Would
this be a good time to include the plugin with Firefox and/or Camino and/or
Seamonkey?




    
    

    
  
Steven mentioned in comment #191 he'd like JEP to be reasonably bug-free for a
month before being integrated.  There's still an outstanding bug with Firefox
and keyboard accelerators.

That said, JEP as it currently stands is more bug-free than the currently
shipping version.  It's BSD licensed, so I presume Mozilla could take it
whenever it so pleases.

    
    

    
  
(In reply to comment #206)

The Java Embedding Plugin is certainly in its final lap ... but there
are a couple of problems I'd like to resolve (if I can) before it gets
released to the teeming masses.

First there's the perrenial "flicker" problem (item #1 in my
KnownProblems.txt).  To my knowledge, no one else has ever mentioned
it in any forum.  Am I making too much of it?  Do you people consider
it unimportant?

Second is a problem that ovvldc himself brought up in a Bugzilla
report (bug 258240) but unaccountably never posted to the Java
Embedding Plugin's Bugs tracker :-)

I've confirmed the thread and memory leaks he reports WRT the Java
Embedding Plugin (even the most recent version), and have also
confirmed that the thread leaks (at least) don't happen in Safari.  I
know I'll have to dig deep inside Sun/Apple's JVM to resolve this
problem (if I can resolve it at all).  But I want to at least give it
a try.

Third is an issue that just appeared on Bugtraq:

http://securityfocus.com/archive/1/381940/2004-11-20/2004-11-26/0

I haven't had a chance to look into this.  And I know it's really
Apple's problem to update their JVM to 1.4.2_06.  But I want to make
sure that I'm not inadvertently exacerbating the problem (which means
I'll have to penetrate the deliberate obscurity of iDefense's report,
put there to protect us all).



    
    

    
  
(In reply to message #207)

> There's still an outstanding bug with Firefox and keyboard
> accelerators.

You mean the problem reported at the following URL and discussed in
item #3 of my KnownProblems.txt?

http://sourceforge.net/tracker/index.php?func=detail&aid=1032695&group_id=107955&atid=649116

(By the way, the most recent two comments discuss a completely
unrelated problem.  At some point I need to clean that up.)

I don't consider this problem particularly important, and will
probably leave it unresolved in my 1.0 release.  Likewise with item
#2.



    
    

    
  
Bug 162134 is still broken even with the latest version of JEP. It works better
than the Mozilla version, but still doesn't handle applets in tabs correctly.

    
    

    
  
I have been using the Java Embeding Plugin O.8.7 with few if any problems with
the Suite.

Just my opinion: I believe it would be good to include the pugin with the
downloads of Mac Mozilla products. My only question would be that because the
plugin has not yet reached 1.0 will this create problems with users' plugins
becomming out of date?

    
    

    
  
In reply to comment #210:

Well, bug 162134 has the following description:

expected results:
java applet stays on its own dang tab
actual results:
java applet draws all over any other tab in the same window

Currently (and I tested yesterday) Java doesn't draw on other tabs anymore. Just
leaves one shadow which goes away after a redraw (just scroll down and up
again). So the 'keeps drawing' is solved, at least. It is not perfect yet, but
certainly a lot better. http://www.bbcworld.com is a good test URL.

In reply to comment# 208:

I know, I am so busted.. But the discussion in the other bugs led me to believe
it was not a JEP related issue. Now it seems there may be a number of bugs
compounding each other. So I filed request ID 1073682 with Sourceforge for your
debugging pleasure and convenience :).

Again, Steven, you can wait as long as you feel necessary but JEP is now a vast
improvement over the basic plugin. Of course, the friendly people at
plugindoc.mozdev.org have linked to the JEP page at sourceforge. So everyone
worth his browser should be able to find it.

    
    

    
  
(From comment #212)

> Again, Steven, you can wait as long as you feel necessary but JEP is
> now a vast improvement over the basic plugin. Of course, the
> friendly people at plugindoc.mozdev.org have linked to the JEP page
> at sourceforge. So everyone worth his browser should be able to find
> it.

Naive users won't know (or care) how difficult it was to write the
Java Embedding Plugin, or be particularly tolerant of glaring ugliness
or inconvenience.  So I don't want the JEP to get into too many of
their hands until I've at least made my best effort to eliminate these
kinds of problems.  Ultimately it's a case of not wanting to make a
bad first impression on too many people at once.  Naive
Firefox/Mozilla/Camino users (there are a few) have had to put up with
Java problems on the Mac platform for a long time now.  Asking them to
wait a few more months isn't (I think) such a big deal.

Those who are enterprising enough to complain about this state of
affairs (i.e. to file a bug report at Bugzilla) aren't really so naive
(or helpless) after all.  They can easily be directed to the JEP home
page.  Those who are still more enterprising (those who read the docs
at plugindoc.mozdev.org) can find the JEP on their own.

(From comment #211)

> My only question would be that because the plugin has not yet
> reached 1.0 will this create problems with users' plugins becomming
> out of date?

Yes, this could be a problem.  With the current version (0.8.7), the
Java Embedding Plugin now has checks to prevent version mismatches
between JavaEmbeddingPlugin.bundle and MRJPlugin.plugin.  But I'm not
going to commit to freezing my C/C++ API (or to ensuring backwards
compatibility) until the 1.0 release.  Even JEP 0.8.7 made some API
changes that were incompatible with previous versions (hence the
version checks).



    
    

    
  
(From comment #210)

> Bug 162134 is still broken even with the latest version of JEP. It
> works better than the Mozilla version, but still doesn't handle
> applets in tabs correctly.

(From comment #212)

> Currently (and I tested yesterday) Java doesn't draw on other tabs
> anymore. Just leaves one shadow which goes away after a redraw (just
> scroll down and up again). So the 'keeps drawing' is solved, at
> least. It is not perfect yet, but certainly a lot
> better. http://www.bbcworld.com is a good test URL.

I'll try to get to the bottom of this issue in private email with
jgleigh and ovvldc.  Then I'll post a summary somewhere on the Java
Embedding Plugin's project page and send a note here.

My current impression is that only Mozilla still has serious problems
with applets drawing in other tabs, and that this is probably
Mozilla's "fault".

(From comment #212)

> I filed request ID 1073682 with Sourceforge for your debugging
> pleasure and convenience :).

Thanks! :-)



    
    

    
  
*** Bug 272355 has been marked as a duplicate of this bug. ***

    
    

    
  
I've just released version 0.8.8 of the Java Embedding Plugin:

http://javaplugin.sourceforge.net/

This release fixes the "Sun Java Plugin Arbitrary Package Access
Vulnerability" (a hole in JavaScript-to-Java LiveConnect), which was
reported at:

http://securityfocus.com/archive/1/382072/2004-11-23/2004-11-29/0
http://securityfocus.com/archive/1/381940/2004-11-16/2004-11-22/0

The fix works for both Java 1.4.X (what you get when you use the MRJ
Plugin JEP with JavaEmbeddingPlugin.bundle) and Java 1.3.1 (what you
get when you use the MRJ Plugin JEP by itself).  Earlier versions
(prior to 0.8.8) of the Java Embedding Plugin are vulnerable, in both
configurations.  Users of those versions should upgrade as soon as
possible.

The easiest way to test for this vulnerability is to go to the
following site and select "Choose which tests to run".  The "Arbitrary
Package Access" test is currently the first one listed.

http://bcheck.scanit.be/bcheck/

This vulnerability is ultimately a hole in the JVM, and Sun has
released a new version of their Java Plugin (1.4.2_06) to fix it
(apparently 1.5.0 was never vulnerable).  I originally hoped to wait
for Apple to update their JVMs (1.3.1 and 1.4.X).  But none of their
own products is vulnerable (Java Applet.plugin and early versions of
Safari because they don't support LiveConnect, later versions of
Safari for unknown reasons).  So Apple may never update their JVMs.

So I decided to take care of the problem myself, and was able to find
a way to do it -- hence this release of the Java Embedding Plugin.

In order to address both Java 1.4.X and Java 1.3.1, I put my fix in
the MRJ Plugin JEP.  I wondered if Mozilla.org might want to add my
fix to the version of the MRJ Plugin that they're currently
distributing for Camino users:

ftp://ftp.mozilla.org/pub/mozilla.org/camino/releases/MRJPlugin.gz

But it turns out that this version of the MRJ Plugin has LiveConnect
disabled, so it isn't vulnerable.



    
    

    
  
I have discovered a Major bug with the latest Java Embedding Plugin, version 0.8.8.

This plug-in works fine with the Mozilla suite 1.7RC2.

It will not work with Mozilla 1.8a3. The exact version is listed below:

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a3) Gecko/20040817

I have not tested this plug-in with newer nightlies since the last version I
tested (1.8a4) is too unstable on my Mac.

My Mac is a B&W G3-350 512MB 10.3.6.

THE Problem: After the browser is launched it hangs as the Java Embedding Plugin
is being loaded and the Activity Monitor lists that Mozilla has hung.

When I remove the Java Embedding Plugin 0.8.8 and restore the Java Embedding
Plugin 0.8.7 Mozilla 1.8a3 launches normally.

This bug shows up ONLY in some versions of Mozilla (see above) and not others.
Has this plug-in worked for anyone using Mozilla 1.8a3?

    
    

    
  
I've just released version 0.8.9 of the Java Embedding Plugin:

http://javaplugin.sourceforge.net/

This release fixes several bugs introduced by JEP 0.8.8 and 0.8.7,
including the one described in comment #217.  It changes back to
launching the 1.4.X JVM on demand (whenever Java is used for the first
time in a browser session).  It (almost) eliminates the thread leaks
mentioned in comment #208 and comment #212.  And it fixes a bunch of
memory leaks.

The Sun/Apple Java Plugin normally launches the JVM on demand, and
that's how early versions of the JEP (0.8.0 through 0.8.2) behaved.
I've now figured out how to make this compatible with using
LiveConnect outside of any applet (as do the LiveConnect tests at
http://www.mozilla.org/quality/browser/front-end/testcases/oji/).  But
the main reason for the change is that Mozilla.org is changing future
releases of the Mozilla-family browsers to launch the MRJ Plugin on
demand (https://bugzilla.mozilla.org/show_bug.cgi?id=128366).
Fortuately someone CCed me on that "bug".

Assuming that I've eliminated all the thread and memory leaks that can
be blamed on the JEP, the version 0.8.9 changes leave the following
version 1.0 "blockers":

1. The "flicker" problem (item #1 in my KnownProblems.txt).

2. A small number of keyboard accelerators are disabled in Firefox and
   Mozilla (item #3 in KnownProblems.txt).

3. Applet printing doesn't work.

I used to think the keyboard accelerators problem wasn't very
important, but I've changed my mind -- though only a few accelerators
are disabled, they're important ones, heavily used by sophisticated
users.  Likewise with the printing problem (which I didn't even
mention previously) -- people expect OS subsystems (like printing) to
"just work" on a Mac.

It might turn out that I _can't_ fix the printing problem -- applet
printing may be broken on the browser side (no call is made to
nsIPluginInstance::Print() when you print a page with applets in it).
In that case I'll just blame Mozilla.org :-)

I tried but failed to get to the bottom of the
applets-drawing-in-other-tabs issue mentioned in comment #210 and
comment #212:  I got a detailed recipe from Jeff Leigh, but following
it didn't "work for me" at reproducing the problem.  So, as things now
stand, I consider this problem solved for Firefox and Camino, but
(still) not for Mozilla -- Mozilla 1.7.5 is as bad as previous
versions.  And I don't consider it a blocker.



    
    

    
  
Perhaps some of the people central to the development of Mozilla on the Mac can
tell you what is and what is not implemented (Mike Pinkerton?). No sense in
wasting time tracing a bug that isn't in your code..

Also, bug 162134, which deals with last issue you mentioned, is being swamped
with duplicates. FF popularity may start driving up the popularity of the plugin :).

    
    

    
  
*** Bug 200375 has been marked as a duplicate of this bug. ***

    
    

    
  
The 0.8.9 embedding plugin stopped working on Camino on my system as of the
20050120 build. It works with 20050119 build and earlier. Tested using the page
http://www.java.com/en/download/help/testvm.xml

    
    

    
  
(In reply to comment #221)
> The 0.8.9 embedding plugin stopped working on Camino on my system as of the
> 20050120 build. It works with 20050119 build and earlier. Tested using the page
> http://www.java.com/en/download/help/testvm.xml

WFM using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b)
Gecko/20050126 Camino/0.8+

I'm having issues with an hourly build of Firefox, about which I emailed Steven
off list. Basically, Firefox is crashing without launching Talkback or Crash
Reporter. I suspect recent checkins are the cause, but someone smarter than I
will have to make that determination.


    
    

    
  
Odd because I'm running the same build right now, clean caches, and it doesn't
work for me.

    
    

    
  
(In response to comment #221 and comment #222)

I tested the same nightly that Joel tested (I think) ... and had
trouble.  The tester at
http://www.java.com/en/download/help/testvm.xml tells me that "Java
Runtime Environment is not working on your system".  If you run Camino
from the console you'll see the following error repeated several
times: "CFLog (21): Cannot find executable for CFBundle 0x1d58060
<[path to Camino]/Camino.app/Contents/MacOS/plugins/MRJPlugin.plugin>
(not loaded)".

Someone's bundled the old MRJPlugin.plugin with Camino!  Which of
course breaks the JEP.  And Camino also gets confused (which it
shouldn't) at the presence of two different copies of MRJPlugin.plugin
-- one in its plugins directory and the other in /Library/Internet
Plug-Ins/.

The solution is to trash the copy of MRJPlugin.plugin in Camino's
Contents/MacOS/plugins directory.

I'll open a bug about this.



    
    

    
  
(Following up comment #224)

If you leave Camino's old MRJPlugin.plugin in place but drag the JEP's
MRJPlugin.plugin out of /Library/Internet Plug-Ins/, Java will appear
to work normally.  But Java testers (like the one at www.java.com)
will tell you that you're running Java 1.3.1.



    
    

    
  
(In reply to comment #224)
> (In response to comment #221 and comment #222)
> 
> I tested the same nightly that Joel tested (I think) ... and had
> trouble.  The tester at
> http://www.java.com/en/download/help/testvm.xml tells me that "Java
> Runtime Environment is not working on your system".  If you run Camino
> from the console you'll see the following error repeated several
> times: "CFLog (21): Cannot find executable for CFBundle 0x1d58060
> <[path to Camino]/Camino.app/Contents/MacOS/plugins/MRJPlugin.plugin>
> (not loaded)".
> 
> Someone's bundled the old MRJPlugin.plugin with Camino!  Which of
> course breaks the JEP.  And Camino also gets confused (which it
> shouldn't) at the presence of two different copies of MRJPlugin.plugin
> -- one in its plugins directory and the other in /Library/Internet
> Plug-Ins/.
> 
> The solution is to trash the copy of MRJPlugin.plugin in Camino's
> Contents/MacOS/plugins directory.
> 
> I'll open a bug about this.
> 
>

You know what, I'm using "davedit's" G4 Optimized build of Camino (from the
Camino Mozillazine forum), which, looking inside its Plugins directory, does not
contain the old MRJ. 

    
    

    
  
Re: comment 224, I reported bug 280050 against Camino earlier today.  I'll
update that bug to reflect the comments here.  Thanks!

    
    

    
  
Thanks!  You've saved me the trouble.


    
    

    
  
Note of warning to users of the Java Embedding Plugin:

Apple has just (2005-02-03) released a "WebStart and Java Plugin
Update 1.4.2 FC Seed" on their Developer Connection web site.  It
breaks signed applets in the Java Embedding Plugin.  If you need to
used signed applets (and you might if you do Internet banking), don't
(for the time being) install this update.

I'll be looking for a workaround.  For more information see:

http://sourceforge.net/tracker/index.php?func=detail&aid=1115915&group_id=107955&atid=649116

As far as I can tell (from brief tests I've performed), this update
leaves other Java functionality unimpaired -- including the JEP's
LiveConnect functionality.



    
    

    
  
I've just released version 0.9.0 of the Java Embedding Plugin:

http://javaplugin.sourceforge.net/

It fixes the incompatibility with Apple's "WebStart and Java Plugin
Update", plus a few other bugs -- including some seldom-encountered
crash bugs and a bad interaction between LiveConnect and signed
applets that sometimes caused trouble for users of
http://hushmail.com/.



    
    

    
  
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; de-AT; rv:1.7.5) Gecko/20041217

When I click on http://www.macosrumors.com/ processor activity immediately goes
up to 100%±5% and blocks all other activities. Takes approximately 2 minutes
until I can do anything such as closing the tab. This behavious only appeared
after I updated to 1.7.5 from 1.7.3.

    
    

    
  
I don't see any Java applets there.  Nor do I have any problems.

Tested with Mozilla 1.7.5 on Mac OS X 10.2.8 and 10.3.7.



    
    

    
  
Martin, I frequently had that problem with MacOSRumors.com in the past. It's
related to bug #235968--basically, that the large number of Macromedia Flash ads
on the page consumes all your CPU cycles so nothing else can happen.
(Additionally, you might see that the flash animation begins slowing down, or it
may stop completely, except that one frame will move each time you move the mouse.)

The only workaround is to go to Preferences/Privacy & Security/Images, and
choose "Do not load any images" and "Never" before you go to that site. It
doesn't work to simply go to MacOSRumors.com and select "Block Images from this
Site" in Tools/Image Manager.

Alternately, you can try using Safari when going to that particular site. It
doesn't have the same problem.

-- David

    
    

    
  
(In reply to comment #233)
> Martin, I frequently had that problem with MacOSRumors.com in the past. It's
> related to bug #235968--basically, that the large number of Macromedia Flash ads

I don't have this issue. I believe that it's because I have the advertisements
blocked using AdBlock to prevent the system from slowing down when someone loads
a large Flash animation without considering that some users can't display it and
not have problems. Blocking images the way you're describing doesn't, I think,
affect Flash (though I don't think I've actually tested to see what happens as
I've always killed annoying Flash applets via AdBlock). It probably only works
on things embedded via the IMG tag. Since the Flash applets are never loaded by
the browser at all, they have no chance to cause problems.

I don't know why sites would willingly use so much Flash especially when it's
causing problems for the users of the specific platform whose users they are
targeting with their site.

    
    

    
  
Jennifer, using the "Do not load any images" and "Never" settings *will* block
the Flash animations--I checked before writing the message. But, "Block Images
from this Site" doesn't block them, since, as you notes, Flash animations are
treated differently. Additionally, it doesn't work to try to figure out which
servers the ads are coming from and block those, probably for the same reason.

I've been able to block them with Privoxy, as you have with AdBlock. It does
work, but if someone doesn't mind Flash in general--just that this page overdoes
it--then there's no good solution.

The question now is: Since Safari can use the same Flash plugin on that site and
not eat up all the CPU, then why hasn't Mozilla been changed to fix the problem.
Obviously, even if there's a defect in the plug-in, Apple's figured out how to
work around it. Maybe the reason it's not fixed in Mozilla is that it's not a
problem with a lot of sites, just with a few.

-- David

    
    

    
  
This bug is not beign worked on. Both the "Assigned To" and the "QA Contact"
email addresses are rejected:
The original message was received at Wed, 9 Feb 2005 10:38:13 -0800
from apache@localhost

   ----- The following addresses had permanent fatal errors -----
<beard@netscape.com>
    (reason: 552 Recipient Rejected: Sorry, the mailbox for beard@netscape.com is
full, please try resending mail later)
<dsirnapalli@netscape.com>
    (reason: 550 Recipient Rejected: This user does not have an account here)

   ----- Transcript of session follows -----
... while talking to mail.netscape.everyone.net.:
>>> RCPT To:<dsirnapalli@netscape.com>
<<< 550 Recipient Rejected: This user does not have an account here
550 5.1.1 <dsirnapalli@netscape.com>... User unknown
>>> RCPT To:<beard@netscape.com>
<<< 552 Recipient Rejected: Sorry, the mailbox for beard@netscape.com is full,
please try resending mail later
554 5.0.0 Service unavailable

    
    

    
  
> This bug is not beign worked on.

Maybe not by mozilla.org.  But do take a look at:

http://javaplugin.sourceforge.net/



    
    

    
  
isn't this more than an enhancement by now?

    
    

    
  
Is there any chance that Stephen's Plugin can be integrated with FF 1.1?

Besides the additional functionality offered by the plugin (1.4 API,
LiveConnect), it seems that Apple's 1.3.x functionality isn't being
well-maintained by Apple, and many applets work properly with 1.4 and this
plugin, while they cause hangs or crashes with Apple's (not really maintained)
1.3.x plugin.

    
    

    
  
Speaking of which, I've just released version 0.9.1 of the Java
Embedding Plugin:

http://javaplugin.sourceforge.net/

The big change is that it's now compatible with Mac OS X (Tiger).  But
I've also managed to fix (or workaround) two problems in my (short)
list of version 1.0 blockers -- Command-H and Command-Q now work
correctly in Carbon browsers (Firefox and Mozilla), and I've got a
workaround for what I call the Camino "spurious updates" bug.

That still leaves a couple of other blockers from my list above
(comment #218), plus one other (possibly major) bug (number 1086810 in
the Java Embedding Plugin's Bugs tracker).

By the time the JEP has reached version 1.0, it should be safe to
release into the hands of tens of thousands of naive users.  At that
point I'd be happy to have it incorporated into any or all of the
Mozilla-family of browsers, as a snapshot or image (so that it can
keep its separate identity and BSD-style license).

(No, I haven't yet opened a bug about the Camino "spurious updates"
problem.  I'll do that in the next few days.)



    
    

    
  
Kudos on the Tiger work, Steven.

Updating summary to reflect Java 1.5 support:

WAS:
 Support Java 1.4.x applets, JavaPluginCocoa.bundle
NOW:
 Support Java 1.4.x/1.5.x applets, JavaPluginCocoa.bundle
Summary: Support Java 1.4.x applets, JavaPluginCocoa.bundle → Support Java 1.4.x/1.5.x applets, JavaPluginCocoa.bundle

    
    

    
  
> (No, I haven't yet opened a bug about the Camino "spurious updates"
> problem.  I'll do that in the next few days.)

I've opened bug 293813, "Camino updates Java applets on every
keystroke (too often)",



    
    

    
  
I've just released version 0.9.2 of the Java Embedding Plugin:

http://javaplugin.sourceforge.net/

It fixes a big security hole (in JavaScript-to-Java LiveConnect) that
effects all nightlies, alphas and betas (everything on the "trunk")
issued since 2004-04-25, but none of the stable releases (on the
"Aviary" and "Mozilla 1.7" "branches").  So users of Firefox 1.0.X,
Mozilla 1.7.X and Camino 0.8.X, for example, aren't vulnerable.

The problem was triggered by changes (on the trunk) to the
nsIScriptSecurityManager interface.  But because LiveConnect continued
to appear to function normally, I wasn't aware of the problem until I
stumbled across it a few days ago.  JEP 0.9.2 now accomodates these
changes, and future changes to this interface will (or should) break
LiveConnect, instead of allowing to proceed without security checks.

For more information see:

http://javaplugin.sourceforge.net/nsIScriptSecurityManagerVuln.html

It also cleans up my workaround for the Camino "spurious updates" bug,
which I introduced in JEP 0.9.1.



    
  
No longer blocks: majorbugs

    
    

    
  
I'm guessing this won't be ready in time for the 1.1 release by this late stage?
Either way, would you have time to give us a status update, Steven? :)

Also, as linked by Bill in comment 204, the Apple Java faq says:
"If you would like to see your favorite browser use 1.4.x on Mac OS X, please
contact the vendor and ask them to work with Apple to adopt the newer version."

So it kinda sounds like they have a solution to offer. Has anyone at Mozilla
tried to approach them about this? Or is it something that Apple would charge
ridiculous sums of money for?

cheers

    
    

    
  
> would you have time to give us a status update, Steven? :)

I'm about to release a new version of the Java Embedding Plugin.  It
won't (yet) be version 1.0 (among other things, applet printing still
doesn't work).  But it _might_ get included in Camino 0.9.  (I told
the Camino folks that, since Camino itself would still be in beta, my
next release should be good enough to include with it.)

> Also, as linked by Bill in comment 204, the Apple Java faq says: "If
> you would like to see your favorite browser use 1.4.x on Mac OS X,
> please contact the vendor and ask them to work with Apple to adopt
> the newer version."

It seems that OmniWeb has taken them up on their offer (recent
versions support Java via the JavaPluginCocoa.bundle, though the last
time I looked OmniWeb's Java still didn't work in Tiger).  I've no
idea how much they paid Apple ... or whether any money changed hands
at all :-)

The release notes for Apple's "J2SE Release 1" also refer to a "new
Cocoa Java Plugin public API" which "can be used to embed Java into
your Cocoa application".  I don't know whether this is what OmniWeb
uses.  But it's _very_ low level (there's just a single Java API call,
which lets you (and requires you to) use JNI).  Using it to build a
Java plugin interface would be almost as much work as writing the Java
Embedding Plugin from scratch, and involve the use (at least) of many
undocumented Java APIs.  Moreover it can only be used by Cocoa apps.

http://developer.apple.com/releasenotes/Java/Java50RN/index.html



    
    

    
  
> http://developer.apple.com/releasenotes/Java/Java50RN/index.html

Oops, my URL only takes you part of the way -- select "New Features"
(on the left), then "Java Applets".  And (of course) the release notes
are for "J2SE 5.0 Release 1".



    
    

    
  
(In reply to comment #245)

Thanks for the update. Glad it's still progressing :)

> > Also, as linked by Bill in comment 204, the Apple Java faq says: "If
> > you would like to see your favorite browser use 1.4.x on Mac OS X,
> > please contact the vendor and ask them to work with Apple to adopt
> > the newer version."
> It seems that OmniWeb has taken them up on their offer (recent
> versions support Java via the JavaPluginCocoa.bundle, though the last
> time I looked OmniWeb's Java still didn't work in Tiger).  I've no
> idea how much they paid Apple ... or whether any money changed hands
> at all :-)

It still might be worth checking, or getting a Mozilla staff member to. Perhaps
they'd at least give you the documentation for what you've been reverse engineering.

> The release notes for Apple's "J2SE Release 1" also refer to a "new
> Cocoa Java Plugin public API" which "can be used to embed Java into
> your Cocoa application".  I don't know whether this is what OmniWeb
> uses.  But it's _very_ low level (there's just a single Java API call,
> which lets you (and requires you to) use JNI).  Using it to build a
> Java plugin interface would be almost as much work as writing the Java
> Embedding Plugin from scratch, and involve the use (at least) of many
> undocumented Java APIs.  Moreover it can only be used by Cocoa apps.

That's a shame it's not what you need. It sounded promising when I first started
reading the page. So you can't use the "Netscape-style" plug-in framework to
avoid the Cocoa problems?

cheers

    
    

    
  
> Perhaps they'd at least give you the documentation for what you've
> been reverse engineering.

Part of the reason Apple has been so reluctant to document how other
browser vendors can use Java 1.4.X and 1.5.X, is (I strongly suspect)
that they don't really have a good answer themselves.  The
"documentation" probably doesn't exist (at least in any reasonably
complete form).  And it would be very difficult to write, given the
hackish and clumsy methods that are required ... as you can see for
yourself in my source code :-)

> So you can't use the "Netscape-style" plug-in framework to avoid the
> Cocoa problems?

The "Netscape-style" plugin they're referring to is (presumably) the
Java Applet.plugin, which uses Java 1.3.1 via the Java Embedding
Framework.  But that's only for Java 1.3.1.  Moreover, Java 1.3.1 and
the Java Embedding Framework are disappearing in the migration to
Intel ... along with (presumably) the Java Applet.plugin itself.


No longer blocks: 163468

    
    

    
  
I've just released version 0.9.3 of the Java Embedding Plugin:

http://javaplugin.sourceforge.net/

I've sustantially improved my workarounds for what I've been calling the
"Camino spurious updates bug", and have also fixed or worked around a lot of
other bugs.

Talking about the "Camino spurious updates bug" is a bit unfair:  Though the
problem is worse in Camino 0.8.4 than in the other "branch version" browsers,
all of them have this problem to some extent.  And the problem is worse still
in recent "trunk" versions of Camino and "Deer Park" (including the latest
nightlies).

The problem (which I will now call the "Mozilla family spurious updates
problem") is very complex, and (for that reason) may never be resolved
completely.  This is why I've spent so much time developing workarounds.  I
think the JEP 0.9.3 workarounds are the best yet ... but there's probably
still room for improvement.

The symptom of a spurious update is that an applet flashes unnecessarily (and
annoyingly).  Without my workarounds, this will often happen several times a
second.



    
    

    
  
*** Bug 303783 has been marked as a duplicate of this bug. ***

    
    

    
  
From the dup: By default on Mac OS X 10.4, Firefox uses a version of Java with
public security holes (Java 1.3.1).
Flags: blocking1.8b4?
Whiteboard: plugin solution: http://javaplugin.sourceforge.net/ → [sg:investigate] plugin solution: http://javaplugin.sourceforge.net/

    
    

    
  
Josh, can we make this happen for 1.5?
Assignee: beard → joshmoz
Flags: blocking1.8a1-
Flags: blocking1.4b-

    
    

    
  
We haven't been able to get this working in our (Josh's) developer builds. If we
can't make this work, then we can't block on it. If we can get this working in
developer builds, please attach a patch and request approval. We'd consider
taking this if it can be made to work. 
Flags: blocking1.8b4? → blocking1.8b4-

    
    

    
  
> We haven't been able to get this working in our (Josh's) developer builds.

Is this due to problems with the Java Embedding Plugin, or to something else?

If there are problems with the Java Embedding Plugin, they need to be reported
to me (preferrably using the JEP's Bugs "tracker").

http://javaplugin.sourceforge.net/
http://sourceforge.net/tracker/?atid=649116&group_id=107955&func=browse

Up til now I've received a few vague reports of problems specific to recent
Deer Park builds, but no useful information.

So, whoever wants to see the Java Embedding Plugin bundled with Firefox 1.5,
test the current JEP versions (JEP 0.9.3 or one of the "nightlies") with
recent Deer Park nightlies.  Bang away as hard as you can, and report
whatever problems you find.  The reports do need (of course) to be precise,
reasonably complete, reproduceable, and include one or more examples.



    
    

    
  
I should mention that version 0.9.3 of the Java Embedding Plugin is already
being bundled with current Camino nightlies (starting with 2005-07-29-08), and
that I have received several good reports of problems specific to the JEP and
Camino (mostly specific to "trunk" (and now "1.8-branch") versions).

Of these, I've (mostly) fixed one (the fix is included in the 0.9.3+a
"nightly", which I've recommended be bundled with future Camino nightlies):

https://bugzilla.mozilla.org/show_bug.cgi?id=302712

I'm about to release a fix for another (in a new JEP "nightly"):

https://bugzilla.mozilla.org/show_bug.cgi?id=302606

And yet another I've found isn't caused by the Java Embedding Plugin:

https://bugzilla.mozilla.org/show_bug.cgi?id=303470

The last one I'm still working on:

https://bugzilla.mozilla.org/show_bug.cgi?id=302843

Thanks to the reporters (and commenters) of these bugs!  A lot of care and
effort has gone into them.

And thanks in advance to whoever else feels like joining the fray! :-)

(Side note:  Please don't report bugs here.  It's much better to report them
at the JEP's Bugs tracker or in individual, new, bugzilla bugs.)



    
    

    
  
Note: Steven Michaud's JEP plugin is now being bundled with all Mozilla Mac
products that use plugins, including Firefox. Thanks Steven!

    
    

    
  
(In reply to comment #256)
> Note: Steven Michaud's JEP plugin is now being bundled with all Mozilla Mac
> products that use plugins, including Firefox. Thanks Steven!

Does this mean that the comment on the whiteboard is obsolete now? In other
words, should we remove that?

And, OT, for those having installed a Firefox with the JEP plugin bundled, do we
need any steps to start using the BUNDLED plugin instead of the prior band aid?

    
    

    
  
> Thanks Steven!

You're most welcome.  And thanks in turn to everyone who has tested the Java
Embedding Plugin and filed bug reports on it ... including many of you on this
list.

> And, OT, for those having installed a Firefox with the JEP plugin bundled,
> do we need any steps to start using the BUNDLED plugin instead of the prior
> band aid?

You don't need to do anything special.  Leave in place the copies of the Java
Embedding Plugin that you've already installed (to /Library/Internet
Plug-Ins/), and upgrade them as new versions come out.  The bundled copies are
in the browsers' Contents/MacOS/plugins directories, which are checked first
by every Mozilla-family browser.  So, for a given copy of a Mozilla.org
browser, whatever's in its Contents/MacOS/plugins directory overrides
whatever's been installed anywhere else (i.e. in /Library/Internet Plug-Ins/
or ~/Library/Internet Plug-Ins).

You might want to remove the JEP version in a particular browser's
Contents/MacOS/plugins directory (so that the browser will use a newer version
in your /Library/Internet Plug-Ins/ directory), or just replace the copy in
the Contents/MacOS/plugins directory, if the newer version fixes a problem
you've been having.  Otherwise leave things as they are.

Note:  If you only use the JEP from a browser's Contents/MacOS/plugins
directory, you'll never have to worry about the nasty "touch /Library/Internet
Plug-Ins/MRJPlugin.plugin" business again!


    
    

    
  
thanks to stephen and josh for making this happen.  shouldn't this be marked as
RESOLVED FIXED, now?

    
  
Assignee: joshmoz → smichaud
Target Milestone: --- → mozilla1.8beta4

    
  
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED

    
    

    
  
The problem was gone, but unfortunately it reappeared with tonight's built
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20050831
SeaMonkey/1.1a

    
    

    
  
I just tried this (the 2005-08-31-12-trunk build downloaded from
ftp.mozilla.org) and had no problems.  I tested with
http://www.java.com/en/download/help/testvm.xml.

Please open a new bug report, giving URL examples and describing your
problem in some detail.  Then post the bug number here and I'll take a
look at it.

    
    

    
  
> had no problems

I continued to play with this SeaMonkey nightly (using the java.com
URL), and just once I saw the "missing plugin" graphic (instead of
the version test applet).  But I'm not able to reproduce this.

I also had one crash (also unreproduceable) while typing a URL in the
location bar.  (I didn't get a crash log -- I had to kill the
process.)

Maybe the SeaMonkey nightlies have just gotten a bit flaky :-)

(I should mention that all my tests were on OS X 10.2.8, which may
be a factor.)


    
    

    
  
Steven,

I have the problem on this page:
http://www.europeantour.com/news/default.sps?iTourID=1 . I reported it earlier
in Bug 219676 but it then was marked a duplicate of this one. In most cases
seamonkey simply freezes and I have to force-quit it, once it crashed but the
crash reporter did not activate.

    
    

    
  
> http://www.europeantour.com/news/default.sps?iTourID=1

I don't have any problems with this URL.  I tested with the
2005-08-31-12-trunk SeaMonkey nightly on OS X 10.2.8, 10.3.9 and 10.4.2.  I've
confirmed that a news ticker applet does get loaded ... but in my tests it
worked just fine (and it did use Java 1.4.X or 1.5.0, as appropriate).

Check that your copy of SeaMonkey has MRJPlugin.plugin and
JavaEmbeddingPlugin.bundle in its Contents/MacOS/plugins directory, and check
that their versions match (both should be 0.9.3+b).

If you do manage to get a new crash log, attach it to bug 219676.

> just once I saw the "missing plugin" graphic (instead of the version test
> applet)

I've now seen this again, and I'm pretty sure it's caused a bug/design-flaw in
Apple's UI (all OS X versions):  When you drag-move or drag-copy a file (or
bundle), it appears in its new location (and disappears from the old one)
before the move/copy operation has actually been completed.  Both times I saw
the "missing plugin" graphic, it was just after I'd moved or copied
MRJPlugin.plugin from one location to another.


    
    

    
  
I've just released version 0.9.4 of the Java Embedding Plugin, mostly to get
it working with Apple's Java Security Update for Mac OS X 10.3.X, which came
out a couple of days ago (not previously announced, without any pre-releases
having been made) and broke the JEP:

https://bugzilla.mozilla.org/show_bug.cgi?id=308549

Version 0.9.4 also fixes some other problems -- most of which only effect
recent pre-release versions of Firefox or Camino.  Many of these fixes have
already appeared in JEP "nightlies".

http://javaplugin.sourceforge.net/

I'm hoping to get it into the trunk and 1.8 and Camino-1.0 branches reasonably
quickly.



    
    

    
  
Steven,

could this problem, the missing frame on the bottom of the page when you click "Weiter", be associated with MRJ?
http://www.porsche.at/d/modelle/configurator/fr_911Coupe4s.htm

    
    

    
  
> Steven,
>
> could this problem, the missing frame on the bottom of the page when you
> click "Weiter", be associated with MRJ?
> http://www.porsche.at/d/modelle/configurator/fr_911Coupe4s.htm

Nope.  There are no Java applets on either of those two pages.

Whiteboard: [sg:investigate] plugin solution: http://javaplugin.sourceforge.net/ → plugin solution: http://javaplugin.sourceforge.net/

    
  
Product: Core → Core Graveyard

          You need to log in
          before you can comment on or make changes to this bug.