Closed Bug 97613 Opened 23 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: