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 ...
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Support Java 1.4.1 applets → Support Java 1.4.1 applets, JavaPluginCocoa.bundle
unless you are a Mozilla driver, you are not authorized to set blocking (+) flags. you can request them (?)
Sorry... I guess that is a bad UI (it was confusing)... anyway it is requested.
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.
here's a page on using a Cocoa UI widget in a Carbon app: http://developer.apple.com/documentation/Cocoa/Conceptual/CarbonCocoaDoc/cci_chap3/chapter_3_section_4.html#//apple_ref/doc/uid/20001516/TPXREF156 and classdump output on the bundle: http://cocoa.mamasam.com/MACOSXDEV/2003/09/2/73688.php hope that helps somebody.
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 :-)
(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.
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!
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.
Created attachment 148080 [details] This is a screenshot of the Java test page 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.
Created attachment 148126 [details] 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.
Created attachment 148212 [details] 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.)
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?
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.
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.
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!
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.
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 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 ----- <email@example.com> (reason: 552 Recipient Rejected: Sorry, the mailbox for firstname.lastname@example.org is full, please try resending mail later) <email@example.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:<firstname.lastname@example.org> <<< 550 Recipient Rejected: This user does not have an account here 550 5.1.1 <email@example.com>... User unknown >>> RCPT To:<firstname.lastname@example.org> <<< 552 Recipient Rejected: Sorry, the mailbox for email@example.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'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.
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).
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
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
Last Resolved: 13 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/
You need to log in before you can comment on or make changes to this bug.