Closed Bug 97613 Opened 24 years ago Closed 18 years ago

build MRJ Plugin: navigator.javaEnabled() always returns false

Categories

(Core Graveyard :: Java: OJI, defect, P1)

Product:
Core Graveyard
Component:
Java: OJI
Platform:
All
macOS
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.6beta

People

(Reporter: tpowellmoz, Assigned: sfraser_bugs)

References

(
URL
)

Details

(Keywords: topembed+, Whiteboard: edt_c3, edt_d3)

Attachments

(2 files)

Patch to allmakefiles.sh and mozilla/Makefile.in
18.91 KB, patch
Details | Diff | Splinter Review
Changes to build the MRJPlugin project correctly in objdir builds
19.71 KB, patch
Details | Diff | Splinter Review
This seems to be a mac specific problem. This may be related to the fix made in bug 56124 and checked in as part of bug 68933. To summarize, navigator.javaEnabled() should return true if the client is able to start and run java applets. This is based on both the state of the Enable Java checkmark in Edit->Preferences, Advanced and the installation of the Java plugin/VM. On Mac system 9.2 (and OS X), the operating system includes the Java VM. I have the latest Mac OS Runtime for Java (MRJ) (version 2.2.5) installed, but no matter what I do with toggling the pref, javaEnabled returns false. Expected: javascript:alert(navigator.javaEnabled()) should return true if the Enable Java pref is checked and MRJ is installed. Actual: It returns false no matter what. About:plugins shows that MRJPlugin is available. Are the plugin and MRJ different? Is there something special that needs to be configured to get this to run? The list applet at the top right runs as expected at http://java.sun.com, but typing javascript:alert(navigator.javaEnabled()) returns false. This was observed with the Netscape 6.1 release (gecko 20010726 0.9.2.1 branch) as well as with Mozilla builds before that.
MAC.
Assignee: edburns → tnoyes
FYI, I'm seeing near identical behavior (failure) with K-Meleon 0.5. I copied the OJI/Java dlls into the K-Meleon plugins folder and java works fine going to http://sun.java.com. However, navigator.javaEnabled() returns false on this browser. Is there a registry setting or pref that affects javaEnabled?
Seems to be fixed in 2001100108? Can someone confirm?
The bug can be observed at http://segal.org/navigator/index.html, which lists JavaScript properties and method return values.
This is fixed in Netscape 6.2 for Macintosh OS 9. I can't evaluate the situation in Netscape 6.2 for Macintosh OS 10.1. The navigator.javaEnabled method reports false even after a Full installation that claims to offer Java, but this reporting may be correct since it appears there is no Java Plugin with Netscape 6.2 for OS X.
I'm seen this also on Win 2000 build 2002012203, so Platform should be "ALL"
Is this bug really still valid?
Assignee: tnoyes → joe.chou
This bug WFM on W2000 build 2002022103. But this seems to be related to MacOS Platform and maybe is waiting for MacOSXJavaPlugin to land. See http://komodo.mozilla.org/planning/branches.cgi
I am seeing this bug on Linux build 2002041421 and Mac OS X build 2002041203 so it is not just a Mac bug.
Java on Mac--->bnesse, but I think this may be a DOM bug
Assignee: joe.chou → bnesse
Using the test case link from comment #4, this WFM using current builds on Mac OS 9, Mac OS X, and Win2k. This failed initially for me on Linux because I had to install Java. After exiting and restarting the application, it worked there too. One thought is that in the nsJVMManager where the state switch is handled there is some logic problem. Those of you that had trouble... are you toggling the state and then checking the value, or checking the value after launching when Java is already active? ->oji component owner
Assignee: bnesse → joe.chou
OS: Mac System 9.x → All
Hardware: Macintosh → All
QA Contact: pmac → petersen
reassign to me
Assignee: joe.chou → joshua.xia
Reporter, I can't find applet from http://java.sun.com and other URL in this bug seems are broken. So, I'm closing this bug. If you can reproduce it in latest JRE, just feel free to reopen. Thanks!
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
This bug was definitely not invalid. It should probably be resolved as worksforme, although more likely it was a duplicate of something else that was fixed. I do not currently have easy access to a Mac, so I can no longer test this. There are other sites that have Java applets that can be tested, for example: http://toc.oscar.aol.com/tic.html This bug is about a JavaScript problem that affected Mac OS 9 and OS X, which come with a Java VM. After installing Mozilla (or Netscape 6/7), you can run Java applets, but the JavaScript method navigator.javaEnabled() would always return false. I suspect that this bug has been fixed based on comment 11.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
This bug was present on Netscape 6.1 on Macintosh OS 9. It was fixed in Netscape 6.2 on OS 9 and works properly on Netscape 7.0 on OS 9.2.2. The bug was present on Netscape 7 PR 1 for OS 10.2 but fixed in Netscape 7.0 on OS 10.2.3. I have not tested on Mozilla builds, but unless there is a problem there, this bug should be closed.
Updating the URL to have the call to the JavaScript method. First test whether the browser can run Java applets, such as with http://toc.oscar.aol.com/tic.html If you can, then test the URL to see if the JavaScript is working. (It should return true.) I'm mostly concerned about Mozilla and not Netscape in this case because it needs to work for all browsers based on Mozilla. Are some assumptions made in the code for navigator.javaEnabled() that won't work on other Mozilla-based (or Gecko-based) browsers that support Java? (See my comments about this also failing in K-Meleon.) Perhaps this is a developer documentation issue?
URL: http://java.sun.com → javascript:alert('navigator.javaEnabl...
Mac->beard@netscape.com
Assignee: joshua.xia → beard
Status: REOPENED → NEW
*** Bug 190584 has been marked as a duplicate of this bug. ***
Setting this back to a Mac bug. Based on duplicate this is still broken for MacOS X.
OS: All → MacOS X
Hardware: All → Macintosh
This bug isn't present i Chimera 2002-12-20-04. As for testing http://www.e-boks.dk/ does a test of javaEnabled and sets a humanly readable cookie based on the value returned. That's how I initially discovered this issue. I then visited this site with Chimera and opened the cookie.txt in BBEdit. In the Chimera cookie file the javaEnabled cookie was set to true. Based on the Mozilla Forum http://www.mozillazine.org/forums/viewtopic.php?t=5073&sid=60e1e3d1825c5b0047939bbb00d95af5 this seems to block functionality on a lot of interactive sites :-( *IF* the site does a check of javaEnabled - otherwise the JavaApplet just executes as expected
*** Bug 195901 has been marked as a duplicate of this bug. ***
I had never gotten a java applet to appear on a page in a Mach-O version of Mozilla (OSX 10.1.5) Thought this might be because Jaguar uses JDK 1.4.1 and pre-Jag was JDK 1.3.1 so I lived with it. However, I got it to work, heres how: I copied the MRJplugin.plugin from version 0.7 Camino.app/contents/MacOS/plugins and put it in the Mozilla.app/contents/MacOS/plugins folder. I tested it on the site from comment #20 (http://www.e-boks.dk), and the cookie value for "java-enabled" now returns "true". Applets now work also: http://java.sun.com/docs/books/tutorial/applet/practical/properties.html I'm new here and not a techie, but I hope this helps.
Plug-in also works if installed in: Macintosh HD/library/internet plug-ins. By the way, just installed Mozilla 1.3rc OSX and had the same problem, no java until I installed the MRJ plugin from the Camino package.
joel: that sure helps :-) at the very least it gives us a very good workaround. now, when I looked into the plugins folder in Mozilla 1.3rc1 there was no MRJ plugins while there was one present in Camino. could the reason for this problem simply be because the Mozilla mac people have forgotten to include the MRJplugin with MachO Mozilla ??? If so, it ought to be a very simple fix, and should be able to reach 1.3final. Proposed fix: include the Camino MRJplugin.plugin with Mozilla I'm raising the awareness by proposing this to be a 1.3 blocker
Flags: blocking1.3?
I'd like to see this fixed too, but release 1.3 is 3 ½ weeks late already. We can wait a little longer for the good of the community.
Severity: normal → major
Flags: blocking1.3? → blocking1.3-
1.4a, on the other hand...
Flags: blocking1.4a?
francis, I'm in complete agreement with you as to the low impact of this problem as it's only an issue at sites that do check through navigator.javaEnabled(), and I wouldn't have set the 1.3? flag unless I had seen an immediate possible solution to the problem. Now, I've taken a look into the 1.2.1, Chimera 0.6 & Camino 0.7 packages. In all of these there's a MRJplugin.plugin in the plugin folder, and none of these has this problem. On the other hand, neither 1.3rc1 nor trunk build 2003-03-07 has this plugin in the plugin folder and they do have this problem. So, my assumption is, that somebody has forgotten to put this plugin into the MachO build and if that is the case, it ought to be a very simple fix, as copying the plugin from Camino into one of the places where Mozilla will be looking for it - as described in comment #22 & #23 - fixes this bug. I've tested and verified that the workaround / fix as found by Joel Craig is indeed working with both 1.3rc1 and trunk build 2003-03-07.
Frankie, unless you're managing 1.3 branch checkins, don't touch the blocking flags. If indeed this is as simple as including MRJplugin.plugin, that'd be great.
Flags: blocking1.3- → blocking1.3?
-->taking bug
Assignee: beard → peterl
Priority: -- → P1
Summary: navigator.javaEnabled() always returns false on Mac → build MRJ Plugin on Mach-O: navigator.javaEnabled() always returns false on Mac
Whiteboard: Workaround: Use MRJ plugin from Camino package
Target Milestone: --- → mozilla1.4alpha
We need this for 1.3 if it means Java doesn't work without it. Peterl, if this is just a packaging issue, a fix shouldn't be difficult or risky, right?
Flags: blocking1.3? → blocking1.3+
We can't just copy the Camino plugin; it has cocoa hacks in it. We also can't just build the plugin as Mach-O with a PB project, because that breaks objdir builds.
Whiteboard: Workaround: Use MRJ plugin from Camino package
This doesn't seem to impact any of the top online java game sites including Yahoo games. I tested the top 20 google hits for "java games" and none of them failed because of this issue. Is this a widespread problem? If it is, why are there not hundreds of dupes?
Probably because we load Apple's Java plugin, which does everything other than LiveConnect.
apple's plugin comes with 10.2 given the low visibility of our MRJPlugin on the trunk, it may be risky for 1.3
OK, pulling from the 1.3 blocker list. I'll release note this. "Mozilla will use the Apple JVM for users with OS X 10.2. 10.1 users will not have Java with Mozilla 1.3 and LiveConnect does not work at all in 1.3." Is that accurate?
Flags: blocking1.3+ → blocking1.3-
Perhaps this? "The MRJ Java plugin is not available in Mozilla 1.3, so LiveConnect does not work. Mozilla will use Apple's Java Applet plugin, if available, to display applets."
Regarding Asa's remarks in comment #32, this DOES affect Yahoo games in OSX 10.1.x (such as java crossword puzzles), however, everything is fine in 10.2.
Blocks: 197865
looking at the status whiteboard in bug 197105 there seems to be a 1.3.1 release on the way. Is it possible to get this issue fixed for 1.3.1 too ???
Flags: blocking1.4a? → blocking1.4a+
Flags: blocking1.4a+ → blocking1.4a-
These changes allow the Project Builder project to build in objdir builds. The makefile symlinks files in js/liveconnect/classes/netscape/javascript/ into a build-generated NetscapeJava directory (for both objdir and normal builds). More changes are required to actually get the project to build. We need to resolve an issue of where to get jni.h from at build time--the MRJSDK directory, or the JavaVM system framework? The latter seems to contains some broken symlinks after the Java 1.4 update, the former may be stale (indeed, changes were made there on the Chimera branch to deal with 10.1/10.2 differences). Also, many changes need merging from the Chimera branch.
Will this enable JDK 1.4 support as well, or are there missing API hooks from Apple that are not yet public? I tried to find a bug relating to 1.4 support, but couldn't find one. If someone can point me in the right direction, I'll be happy to see if I can help getting JDK 1.4 to work.
Shouldn't the release notes say that this applies to mac only?
Anders, Java 1.4 support is bug 197813. Can MRJ Plugin be changed to use 1.4 when available (since not everyone is running Jaguar, and not all Jaguar users have installed the Java update), or can Mozilla be changed to support JavaPluginCocoa.bundle?
Jaguar does not work properly with MRJ plugin. In Camino and in older builds of Mozilla that included Java, the MRJ plugin had to be deleted in order to get Java to work. The Java that shipped with Jaguar worked with the MachO builds and the 1.4 version of Java also worked. The MRJ plugin caused Mozilla to crash when unloading the Java applet. Perhaps the installer could have a second file that would mount on the desktop that would say install this MRJ plugin if you have Mac OS 10.1.5.
This will not enable JDK 1.4 support.
I'm also seeing this bug in build 20030312. Something interesting that I noticed: javaEnabled() returns false if I start up Mozilla with Java enabled. But... if I go into Preferences, toggle Java off, OK that, go back in, then toggle Java back on again, javaEnabled() reports true. It seems like the value returned by javaEnabled() isn't properly initialized, but it does properly track changes in the related preference done while the browser is up and running. Could this be responsible for some of the "works for me" results some people are getting?
As I understand it, this doesn't prevent applets or plugins from running, but it prevents them from communicating with the browser, each other, or the browser from communicating with the plugins. So applications which rely on DHTML to control plugin behaviour will not work, but applications which are self-contained in the plugin (or applet) will work OK. This would explains some of the "works for me," but could someone on the Mozilla team confirm that it's an accurate assessment? And is it being fixed for 1.4? It's a show-stopper for me.
Here's the deal. Ever since Mozilla went Mach-O (e.g. 1.3b), we stopped building the MRJPlugin. So, Java only works because Mozilla picks up Apple's Java plugin in Library/Internet Plug-ins. And Apple's plugin doesn't do LiveConnect (Java <-> JS communication).
I'm trying to use javaEnabled() so that I can provide a nice, clear message to users if Java is switched off -- much more than I'd like to try to cram into an ALT tag. (Mozilla, unlike some other browsers, doesn't display the content between <APPLET...> and </APPLET> when Java is disabled.) The annoying result of javaEnabled() not working is that I would not only be telling users that Java was disabled when it wasn't, but my convenient link that I asked them to click on, after checking that Java is enabled, would only bring them back to the same incorrect message over and over again. Even if the use toggled Java off and back on again to get past the message, he'd have to go through the same thing the next time he visited my web site. In the meantime, I'll simply use browser sniffing and turn off my javaEnabled() check for Netscape or Mozilla on OS X. These users will have to settle for a brief, ALT-tag supplied message if Java isn't enabled. I'll obviously have to leave this sniff test in, but it'll be nice when I can check the version of Netscape/Mozilla and bring back the better Java checking for those users with later versions. I guess javaEnabled() does work in some earlier versions, but I don't want to do a really hairy version check against a long list of versions.
Simon Fraser wrote: > Here's the deal. Ever since Mozilla went Mach-O (e.g. 1.3b), we stopped > building the MRJPlugin. So, Java only works because Mozilla picks up > Apple's Java plugin in Library/Internet Plug-ins. And Apple's plugin > doesn't do LiveConnect (Java <-> JS communication). Regardless of the plug-in used, couldn't the javaEnabled() function simply consult the state of the "Enable Java" checkbox in the Preferences? Since javaEnabled() does work AFTER this check box is toggled off and then back on again, it would appear that some connection between Preferences and javaEnabled ()'s return value already exists -- perhaps all that's needed is to ensure that the function's return value is initialized from the "Enable Java" preference setting at start-up.
Simon, thanks for responding, but you didn't answer the heart of my question. Whey you say "we stopped building MRJPlugin" it sounds arbitrary. What I want to know is: 1. Is there a problem building the MRJPlugin in the Mach-O environment? 2. If so, what is that problem? 3. Is there a fix planned in the 1.4 timeframe (or ever)? Thanks!
There are a number of reasons why we haven't built the MRJ plugin as Mach-O yet. There are conflicts between the various copies of jni.h in the mozilla tree, and system frameworks. You have to install the 50Mb Java dev tools to get a copy of jni.h in the system framework. We haven't done any work to migrate to Java 1.4. There are issues making a plugin that works on 10.1 and 10.2, and in Cocoa and Carbon apps.
> Regardless of the plug-in used, couldn't the javaEnabled() function simply > consult the state of the "Enable Java" checkbox in the Preferences I'm not sure exactly how this is set up--that might work on the Mac, but on other platforms, we want to know not only that the checkbox is checked but also that there's a VM installed. Just detecting the state of the checkbox in prefs could return invalid information if it doesn't also check for the VM.
Simon, thanks again for your response. You've answered my questions #1 and #2. Now it's clear that there is a problem, and we have some details about what the problem is. I understand that it's rather complex. I also see that the target milestone is listed as "mozilla 1.4 alpha." Well, mozilla 1.4 alpha is out the door. Is there a plan to get this in the next alpha/beta/cr/release? What's the goal?
*** Bug 201086 has been marked as a duplicate of this bug. ***
There are a number of bugzilla bugs filed against Java on OSX. http://bugzilla.mozilla.org/show_bug.cgi?id=197813 http://bugzilla.mozilla.org/show_bug.cgi?id=197453 Can we make this a breaker for 1.4b? I think this is very important.
Keywords: topembed
requested a breaker
Flags: blocking1.4b?
Discussed in edt bug triage. Plussing.
Keywords: topembed → topembed+
Whiteboard: edt_c3, edt_d3
*** Bug 203165 has been marked as a duplicate of this bug. ***
--->Simon's got the patches to merge Chimera's MRJ plugin to the trunk....
Assignee: peterl → sfraser
Target Milestone: mozilla1.4alpha → ---
>>> Simon's got the patches to merge Chimera's MRJ plugin to the trunk.... So the above patches fix this problem? I am willing to try a nightly as soon as these are applied as I REALLY need this fixed. Willing to do whatever it takes ;)
Blocks: 199086
Flags: blocking1.4b?
Flags: blocking1.4b-
Flags: blocking1.4?
if the work for Camino to get this plugin building happens in time for 1.4 we'd consider taking it but we're not going to block the release on this.
Flags: blocking1.4? → blocking1.4-
*** Bug 178329 has been marked as a duplicate of this bug. ***
Multiple issues to be resolved here: * configure test for non-broken Java framework headers * compatibility with 10.1 (jni compatibility) * working correctly in cocoa and carbon browsers
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.6beta
*** Bug 209535 has been marked as a duplicate of this bug. ***
This bug has re-appeared again in Netscape 7.1 for Mac OS X. It was fixed in 7.01. It was broken in 7PR1. It was fixed in 6.2 for Mac OS 9. It was broken in 6.1 for Mac OS 9. Strange, isn't it?
I've seen this bug on linux versions 1.2, 1.3, and 1.4. This definitely is not a Mac only bug. It's easy to recreate, the javaEnabled() function simply returns false until it is toggled off and on. I've just learned to immediately go to the preferences menu whenever I hit a site that I know breaks because of this.
Gary Cauthon's workaround of toggling the "Enable java" preference off and on works also for Netscape 7.1 on Macintosh OS X, as demonstrated using http://segal.org/macjavabugs/enabled/. Unfortunately the therapeutic effect of this maneuver is not retained when the browser is closed and then opened again.
When I first reported this bug it was not a problem with java but javascript, I keep getting warnings parent.frames.right.documents.applets[0].centerOn is not a function. This works fine with Mozilla on Windows and Mozilla 1.2.1 on OS X. But any other version of Mozilla it does not work.
I've also noticed that after doing the off/on toggle of the enable java checkbox, the java console selection under tools->web development becomes available. Clicking on it doesn't bring the console up, but it does cause javaEnabled() to start returning false again (until the next off/on toggle).
Silly me, all I had to do was type: ln -s /usr/j2sdk/j2sdk1.4.2/jre/plugin/i386/ns610-gcc32/libjavaplugin_oji.so /usr/local/mozilla/plugins/libjavaplugin_oji.so Now javaEnabled() returns true without all of the hassle.
> When I first reported this bug it was not a problem with java but javascript, I > keep getting warnings parent.frames.right.documents.applets[0].centerOn is not a > function. This works fine with Mozilla on Windows and Mozilla 1.2.1 on OS X. But > any other version of Mozilla it does not work. Does this START working when you disable/enable Java support on OSX? This is an applet scripting bug. It turns out that applet scripting is broken on Mozilla > 1.2.1 on OSX but I have confirmed that it WORKS on 1.2.1 i wrote my own page to test applet scripting on OSX http://newsmonster.org/applet-test.html
Could someone on OSX help me with this test. If you could to the disable/enable test as below (to 'fix' Java) then visit: http://newsmonster.org/applet-test.html And let me know the results on Mozilla 1.3 or greater. If this works let me know. I know that the applet will load but I am specifically looking for the window.alert() message of "..it worked.." after the page/applet loads. If this DOES fix it then this means that the applet scripting bug is somehow tied to this bug... If this works I will post a workaround to fix Java on OSX with Mozilla 1.3 or greater. Kevin
I tried to run the tests that Kevin A. Burton requested on: http://newsmonster.org/applet-test.html however, my testing was blocked by an Exception as follows: netscape.javascript.JSException at netscape.javascript.JSObject.getWindow(JSObject.java:141) at AppletScriptingTest.start(AppletScriptingTest.java:60) at sun.applet.AppletPanel.run(AppletPanel.java:353) at java.lang.Thread.run(Thread.java:491) The same behavior occurred with Mozilla 1.4 (Gecko/20030624) and Netscape 7.1 on OS X 10.2.6 (6L60). It appears that both browsers were using Apple Java 1.3.1 (MRJ 3.3.2) even though 1.4.1 DP102 (MRJ 4.3) is also installed.
yes... that exception should be raised. Did you try to to the "toggle java enabled" trick before you ran my test? That is what I am more interested in. I know that the test will fail but I am not sure what will happen if java enabled is toggled. Kevin
On Mac OS X with Mozilla 1.4 the same Exceptions come up even after toggling the setting to enable Java. The effectiveness of the toggling was confirmed using http://segal.org/macjavabugs/enabled/
*** Bug 209844 has been marked as a duplicate of this bug. ***
fyi, in case this info it might help, I have seen this behavior, where unless I leave a browser session up all the time, navigator.javaEnabled() always returns false until I disable-then-enable-Java. It is *not* MAC only. I have seen it on several Win2000 systems, with and without Sp3. I have seen it with these versions of Firebird: - Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030516 Mozilla Firebird/0.6 - Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030714 Mozilla Firebird/0.6 Doing a "Download" from http://www.java.com (which (apparently resulted in jre and plugin 1.4.1_04 being installed to my system) fixed the problem for good.
multiple comments claim similar behavior in Windows and possibly Linux. See also bug 5352, bug 24811, bug 44830, et al.
Hardware: Macintosh → All
Summary: build MRJ Plugin on Mach-O: navigator.javaEnabled() always returns false on Mac → build MRJ Plugin: navigator.javaEnabled() always returns false
*** Bug 195724 has been marked as a duplicate of this bug. ***
This bug is still present in ver. 1.4.1 RC1, as checked here: http://gemal.dk/browserspy/java.html Mac OSX 10.2.6
Flags: blocking1.4.1?
*** Bug 219300 has been marked as a duplicate of this bug. ***
I believe this is two bugs that have the same source - A Mac-specific bug apparently involving Apple not supporting LiveConnect, and a Java detection bug that occasionally affects other OSes, which is one symptom of the LiveConnect bug. (see below) The solution to the general mac bug sounds like it's to force Mozilla to use the MRJ instead of Apple's Java, even if the MRJ is old. It sounds like Mozilla 1.2.1 is the last Mozilla to ship with an MRJ - but the release notes for OSX 1.2.1 still say that it uses "the java installed on your system" Can someone confirm this? I have only occasional OSX exposure right now. I could make my users install Moz 1.2.1 if I had to. from bug 219300 ------- Additional Comments From sfraser@aol.net 2003-09-15 13:40 ------- Apple didn't break things. They a) took away the java embedding APIs in Java 1.4 that our MRJ plugin uses, so our plugin was not upgradable to Java 1.4 b) didn't fulfill their promises to implement LiveConnect in their java plugin.
Mozilla 1.0.2 (I am using Netscape 7.01 for Mac OS X) on Mac OS X v10.2 (a.k.a Jaguar) with updated MRJPluginCarbon 1.0.1 from Patrick Beard (found at http://homepage.mac.com/pcbeard/MRJPlugin/) has LiveConnect support. It would be nice if Mozilla 1.4 and Mozilla 1.5 were retrofited to allow using the MRJPluginCarbon 1.0.1 or to use the same APIs as the plugin so that LiveConnect was functional until Apple delivers on their promises.
The javaEnabled() bug is still present in the 1.5rc1 (build 20030916). This was showing up when I was trying to use the StatTracker portion of Yahoo Fantasy Sports. The workaround of toggling Java on/off works, but it would be much nicer if this was fixed before 1.5 was released.
It would be nice if Mozilla went back to shiping with MRJ which was stated that is what Mozilla 1.2.1 did. With the latest Java update from Apple Java applets are not working properly. Until apple gets its act together it might be a good work around.
*** Bug 220211 has been marked as a duplicate of this bug. ***
Flags: blocking1.4.1?
For java games on Yahoo, Popcap, etc. I will try the workaround mentioned in comment #22 above, if I can. But meanwhile I cannot find where to toggle Enable Java in preferences. Mozilla nightly - 2003111303 Mac OS 10.1.5 Has it been removed since java's not working anyway, or is this a sign that someone is working on the problem? //Polly
*** Bug 226031 has been marked as a duplicate of this bug. ***
To enable java: Mozilla/Preferences/Advanced
Thanks - I must have been looking for the word "Java" in the subheadings under advanced. Somehow I missed it, it's there now! And Java IS enabled.
(Yes this is getting too much like a discussion thread.) RE: comment #22 above: The Java games at popcap.com work on Camino. I notice one thing though, in IE I can "push" the Diamond Mine gems, but in Camino the first mousedown counts as a Click and highlights the brackets. The 2nd mousedown will "push", but by then what's the use? Somebody please see that the bug reporting in Camino includes this. I'm not going to go there. I'm a nobody and I don't know how to copy "the MRJplugin.plugin from version 0.7 Camino.app/contents/MacOS/plugins and put it in the Mozilla.app/contents/MacOS/plugins folder." I have to open the app somehow? Will I have to do it again for each Nightly Build? Mozilla build 2003113005, Mac 10.1.5 ///Polly
Polly, To get the plugin out of Camino, you need to alternate click on the Camino Icon (hold Control and click if you don't have a right mouse button), then select "Show package contents." On another note, the milestone for this bug is 1.6 beta which was released today. Am I correct in assuming this is still a valid problem? This bug is of particular interest to me, since my company uses LiveConnect in our product, and the only way we can support Mac for our users is on Mozilla 1.2.1.
I am in the same boat. I have to tell student and faculty mac users to use Mozilla 1.2.1 for any of our educational programs. And since updating to Apples latest java I can not view any images with our java applet.
*Ping* Anyone having any luck with this? Present in Mozilla 1.4.1, Firebird 0.7.1 semi-milestone, and Camino nightly from Jan. 21 and Mac OSX 10.2.8. Pesky little bug, ain't it? Would be nice if someone focused on this, wish I could help, but I'm lacking the necessary knowledge...
I still don't think anyone is working on this... It's really a shame when these type of bugs can exist for so long on such a popular platform as the Mac.
Another note... and I'm hoping some other people are willing to back me up on this one. $50 goes to the first person who fixes this bug. This offer expires March 1... If we can get 10 or so people to back this up maybe we can get a Mozilla developer/contributor to fix this. I would do it myself but I'm crazy busy and don't have a Mac. The fix of course has to make it back into CVS and integrated into Mozilla/Firebird in the next subsequent release. If we can get a few early adopters to back me up here we can setup a website to accept the donations and then get MozillaZine et al to pick this up. Kevin
so is the method just broken? Java works for me on Mac.... Can someone set a breakpoint in the C++ method that gets called from JS here: http://lxr.mozilla.org/seamonkey/source/dom/src/base/nsGlobalWindow.cpp#6011 ...and step through this code to see why it failes. Please try again after you've visited a page with an applet. Could be that nsJVMManager::fStatus is incorrect. Can someone with a debug build check that as well?
Just a reminder that this is ***not*** a MAC only bug. See my previous comment 78: http://bugzilla.mozilla.org/show_bug.cgi?id=97613#c78
Have you tried a trunk Win32 build? I just built one and it seems to WFM. The Mac does indeed fail though and I can't figure out how to get XCode to debug my build ("New Custom Executable" ain't enabling the Debug/Run menu). If anyone knows how to set a breakpoint in XCode for Mozilla, I'll can look at this. My Win32 Moz 1.6a build does indeed fail but I just downloaded 1.6 final and it also WFM.
When URL is performed, the result has returned by true. It was false when it tried before. Does this bug fix? Mac OS X 10.3.2 Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; ja-JP; rv:1.7a) Gecko/20040201 Firebird/0.8.0+
Mac OS X 10.3.3 and latest MRJ still fails. Mozilla 1.7b, Netscape 7.1, firefox all have the same result navigator.javaEnabled()=false. The plug-ins for MRJ are available in the plug-in list.
*** Bug 229312 has been marked as a duplicate of this bug. ***
This is still broken on Netscape 7.2 for Macintosh OS X as demonstrated at: http://segal.org/macjavabugs/enabled/index.html
The java plugin being developed in conjunction with bug 197813 fixes this problem.
I've found a working fix for this problem. Best not to repeat the description of the actual issue and fix here, just visit SourceForge for the "Java Embedding Plugin" page. http://javaplugin.sourceforge.net/Readme.html I've found that it is currently best to install just the MRJPlugin.plugin piece of the package (drag to / Library/Internet Plug-ins), not the JavaEmbeddingPlugin.bundle. You only get Java 1.3.1 this way, but at least it works. You need to sudo touch /Library/Internet Plug-Ins/MRJPlugin.plugin in the Terminal and restart the browser to get it going. EF
Don't do it if you've already installed Apple's latest Java update from earlier this week (Java 1.4.2 Update 1). This plugin does not yet work with the update, and the developer is working to fix it and was hoping to have something by the end of this week.
Commit too soon... Unless you are saying that by just using the MRJ part of it that it is not affected by the latest update?
(In reply to comment #108) > Commit too soon... > > Unless you are saying that by just using the MRJ part of it that it is not > affected by the latest update? Yeah, the MRJPlugin.plugin part only gives you access to the Java 1.3.x stuff that isn't affected by the 1.4 update. The JEP piece enables 1.4 support, and is as such currently broken. I have only the MRJ piece installed and I can get into my intranet - usfconnect.usfca.edu - that used to complain about missing Java.
(In reply to comment #108) > Commit too soon... > > Unless you are saying that by just using the MRJ part of it that it is not > affected by the latest update? Yeah, the MRJPlugin.plugin part only gives you access to the Java 1.3.x stuff that isn't affected by the 1.4 update. The JEP piece enables 1.4 support, and is as such currently broken. I have only the MRJ piece installed and I can get into my intranet - usfconnect.usfca.edu - that used to complain about missing Java.
*** Bug 42749 has been marked as a duplicate of this bug. ***
Blocks: 217384
JEP was updated to 0.8.3 on Aug 21st to support Java 1.4.2 Update 1
*** Bug 263280 has been marked as a duplicate of this bug. ***
Mac OS X 10.3.8, Gecko/20050225 Firefox/1.0.1 still failing. I stumbled upon this bug while debugging Doubleclick tags depending on navigator.javaEnabled() Toggling Java off/on from preferences panel fixes the problem temporarily.
Can we mark this bug FIXED with the Java Embedding Plugin?
Certainly WFM with recent Camino trunk build. Tested with Camino nightly trunk build 2006101622 (v1.2+) running under Mac OS 10.3.9.
Marking this FIXED based on all current Mozilla.org Mac products shipping the JEP from bug 197813.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago → 18 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: