Closed Bug 435334 Opened 16 years ago Closed 16 years ago

[3.1a1pre] Java plugin is not recognized.

Categories

(Core Graveyard :: Java: Live Connect, defect, P1)

Product:
Core Graveyard
Component:
Java: Live Connect
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.9.1a1

People

(Reporter: bugmozz, Assigned: jst)

References

(
URL
)

Details

(Keywords: regression, verified1.9.1)

Attachments

(3 files, 2 obsolete files)

[checked-in] Move the JVM auth tools from modules/oji to modules/plugins/base
31.53 KB, patch
jaas
: review+
sicking
: superreview+
Details | Diff | Splinter Review
#ifdef OJI cleanup patch.
15.15 KB, patch
jaas
: review+
sicking
: superreview+
Details | Diff | Splinter Review
Remove a bunch of Java specific code from our samples.
44.67 KB, patch
jaas
: review+
sicking
: superreview+
Details | Diff | Splinter Review 
Confirmed on Mac OS X

The Java test page (added to URL field) returns: Java Runtime Environment is not working on your system

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1a1pre) Gecko/2008052102 Minefield/3.1a1pre
URL: http://www.java.com/en/download/help/...
OS: Windows XP → All
Hardware: PC → All
Johnny, this was intentional because of the disabling of OJI, correct? WONTFIX, and what are the versions of Java that do work?
Assignee: nobody → jst
If we're going to ship this as 1.9.1/3.1, should we be breaking this?
none of the versions of java work 

version 7 latest snapshot does not work

version 6 does not work 

version 5 does not work

so i cant find a single version that works

Yes, this is intentional. The new plugin is available as a beta already, but not final yet AFAIK.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
Kenneth, could you point us to the beta version here so people can download and test etc?
I just installed Java 6 update 10 b23 that have the Java Addon 1.0, and going to www.time.gov I am still prompted to 'install java' - 

so that's not the answer either...

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1a1pre) Gecko/2008052204 Minefield/3.1a1pre Firefox/3.0 ID:2008052204
Just updated to Java SE 6u10-b24 dated 14-May-08, and the Time.gov site still is prompting to Install Java, clicking the info bar to Install results in 'Fail to install'

Also used today's nightly build of 3.1a1pre as well..

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1a1pre) Gecko/2008052305 Minefield/3.1a1pre Firefox/3.0 ID:2008052305
that beta plugin does not work
Just tested with new profile - same Java is not working... reopening
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
It does look like there has been a recent and severe regression in Firefox 3's
ability to recognize at least the new Java Plug-In.

This nightly build of FF 3 worked:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008052006
Minefield/3.0pre

and this one does not:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008052305
Minefield/3.1a1pre

Reopening and marking as P2, blocking-1.9?
Severity: normal → major
Flags: blocking1.9?
Priority: -- → P2
The blocking-1.9 flag is for blocking the 3.0 release. If 3.0pre works, then this isn't blocking 1.9.
Flags: blocking1.9?
OK, my mistake -- I'm glad that there was no regression in the Firefox 3.0 sources -- but there has definitely been a major and recent regression so please make sure this bug is tagged appropriately to designate that.
Severity: major → normal
Flags: blocking1.9.0.1?
Keywords: regression
Priority: P2 → --
Added 'regression' per comment #14 and req blocking on 1.9.0.1
this is on the 1.9.1 tree not 1.9.0.x 

1.9.0.x is for Firefox 3.0.1 or what ever

1.9.1 is for Firefox 3.1
Sorry, still not totally clear on all these new numbers yet :( Removed req for blocking.
Flags: blocking1.9.0.1?
Could someone make a guess about when this will be corrected, or should we just not bother testing 3.1.a1pre yet ?  


Jim, it would be nice to figure out why it's not being recognized. We have disabled the OJI layer in the 3.1a1pre code, which is apparently causing a problem with the Java plugin recognition, but we don't know what the problem is yet.
Confirmed on linux (Ultimate Edition 1.8 & Ubuntu 8.04) too
Flags: blocking1.9.1?
Confirmed on Windows 2000, too.
Build 25 has been released, and still no java recognition:

https://jdk6.dev.java.net/6u10ea.html#Download

For Vista users, the JavaQuickStart has been disabled in this build, as Vista has its own pre-fetch according to release notes.  

I also see that the JavaQuickStart extension/plugin is also not present. 


This WFM on Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008060407 Minefield/3.0pre ID:2008060407 using 
C:\>java -version
java version "1.6.0_05"
Java(TM) SE Runtime Environment (build 1.6.0_05-b13)
Java HotSpot(TM) Client VM (build 10.0-b19, mixed mode, sharing)
Sorry on the noise, didn't realized the 3.1 =(
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P1
Status: REOPENED → NEW
I've made some progress on this issue already, but not quite done yet. Stay tuned for more updates...
Hey, Johnny, glad to see your working on it.  I will stay tuned. 
This gets Java working again, assuming you have the new NPRuntime enabled plugin installed and activated. This does two things, first it moves ns[I]JVMAuthTool.{idl,cpp,h} from modules/oji into modules/plugin/base. This is needed because the Java plugin depends on these auth tools until the same functionality is exposed through the NPAPI. Secondly, some of the code that is currently inside #ifdef OJI checks that are really not OJI specific in any way, and are needed for us to find the Java plugin etc, so that code is moved outside of #ifdef OJI. There's really no new code here, just code moved around...
Attachment #325673 - Flags: review?(joshmoz)
The logic which searches for the Java Plug-In should be modified in the case where OJI is not #defined. Specifically, it should require the Java Plug-In to be picked up from the bin/new_plugin directory, ignoring any registry setting and bailing out if that isn't found, since presumably the old OJI-based Java Plug-In won't work at all.

(In reply to comment #29)
> The logic which searches for the Java Plug-In should be modified in the case
> where OJI is not #defined. Specifically, it should require the Java Plug-In to
> be picked up from the bin/new_plugin directory, ignoring any registry setting
> and bailing out if that isn't found, since presumably the old OJI-based Java
> Plug-In won't work at all.
> 
I don't really thing relying on default install locations to determine if it is the new or OJI based plug-in is the way to go.  This should somehow instead be determining if it is a supported version via version number or some other more reliable means.

The new non-oji java plug-in appears to be a windows only thing.

Therefore, even with this patch, there is no working Java for Linux.
(In reply to comment #31)
> The new non-oji java plug-in appears to be a windows only thing.
> 
> Therefore, even with this patch, there is no working Java for Linux.
> 

I filed bug 440983 on this issue.

(In reply to comment #28)
> Created an attachment (id=325673) [details]
> Make the new Java plugin work even with OJI disabled.

With this patch included --enable-oji builds fail (at least under Linux).

This is significant because there is no available non-oji java plug-in for Linux.

../../../dist/bin/xpidl -m header -w -I/home/wag/mozilla/mozilla2/modules/oji/public -I../../../dist/idl -o _xpidlgen/nsIJVMManager /home/wag/mozilla/mozilla2/modules/oji/public/nsIJVMManager.idl
/home/wag/mozilla/mozilla2/modules/oji/public/nsIJVMManager.idl:80: Warning: %{ .. %} code fragment within interface ignored when generating NS_DECL_NSIJVMMANAGER macro; if the code fragment contains method declarations, the macro probably isn't complete.
nsIJVMPluginInstance.idl
../../../dist/bin/xpidl -m header -w -I/home/wag/mozilla/mozilla2/modules/oji/public -I../../../dist/idl -o _xpidlgen/nsIJVMPluginInstance /home/wag/mozilla/mozilla2/modules/oji/public/nsIJVMPluginInstance.idl
gmake[5]: *** No rule to make target `_xpidlgen/nsIJVMAuthTools.h', needed by `export'.  Stop.


(In reply to comment #31)
> The new non-oji java plug-in appears to be a windows only thing.
> 
> Therefore, even with this patch, there is no working Java for Linux.
> 

This is incorrect. 6u10 (NPRuntime-based Java Plug-In) builds for Linux are available from http://download.java.net/jdk6/ , linked from https://jdk6.dev.java.net/6u10ea.html#Download . There may be some issues with the self-extracting JRE jar installer. I recommend the Linux self-extracting JDK file. The installation instructions for Linux are on https://jdk6.dev.java.net/plugin2/ .

OH.  Silly me had looked in jre/plugin and then based on comment #29 tried looking for a new_plugin directory and didn't find that either.
(In reply to comment #34)
> (In reply to comment #28)
> > Created an attachment (id=325673) [details] [details]
> > Make the new Java plugin work even with OJI disabled.
> 
> With this patch included --enable-oji builds fail (at least under Linux).

I have a fix for this in my local tree, I'll upload a new patch once I have a chance to...
Attachment #325673 - Flags: review?(joshmoz)
(In reply to comment #37)
> (In reply to comment #34)
> > (In reply to comment #28)
> > > Created an attachment (id=325673) [details] [details] [details]
> > > Make the new Java plugin work even with OJI disabled.
> > 
> > With this patch included --enable-oji builds fail (at least under Linux).
> 
> I have a fix for this in my local tree, I'll upload a new patch once I have a
> chance to...
> 

How would I go about using this patch in Linux? What directory should I place it in, and then what command would run it? Any help would be cool, thank you. 

I have the new jre-6u10-beta-bin-b25-linux-i586-29_may_2008.jar installed in my /opt/jre1.6.0_10 directory

thanks again for you work.


(In reply to comment #38)
> How would I go about using this patch in Linux? What directory should I place
> it in, and then what command would run it? Any help would be cool, thank you. 

I have builds including this patch available at http://www.wg9s.com/mozilla/firefox/
(In reply to comment #39)
> 
> I have builds including this patch available at
> http://www.wg9s.com/mozilla/firefox/
> 

I have tried your Windows build and it now detects the Java plugin okay for me. Java seems to be working okay as well.

I am using "Java(TM) Platform SE 6 U10" (I know there are more recent ones available, but newer java builds have big performance issues for me).

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1a1pre) Gecko/2008062405 Minefield/3.1a1pre
Hey Bill, I tried both of your versions (regular and zip) and they both detect Java Update 6.  You say that they only work with Update 10.  But anyway how can I update the version you have?  If I try to update it to the latest hourly the plugin is no longer detected.
(In reply to comment #41)
> Hey Bill, I tried both of your versions (regular and zip) and they both detect
> Java Update 6.  You say that they only work with Update 10.  But anyway how can
> I update the version you have?  If I try to update it to the latest hourly the
> plugin is no longer detected.
> 
Please use the feedback link on my builds webpage to comment on my builds rather than commenting in this bug.  Commenting in the bug ends up spamming everyone cc'd on the bug.

That said, with the patch installed it will detect either the old style OJI Plug-in or the new style Plug-In that comes with the Update 10 beta version of Java.  However, the old plugin will not work correctly and will most likely cause a browser crash as soon as you reference a webpage that actually uses a Java applet.

Using automatic update will take you to the latest official build which still does not contain this patch.  You would need to download the builds from my site that include the patch.  I usually update them daily.  Check the timestamp on the file to see if the new version is available

This is the first of 3 patches that fixes this. It's the original patch in this bug with a few issues fixed, and the patch is split up for easier reviewing. This patch just moves the JVM auth tools to its new home.
Attachment #326820 - Flags: review?(joshmoz)
Second of 3 patches. This one fixes up a bunch of the #ifdef OJI places in our tree to do the right thing whether OJI is enabled or not.
Attachment #325673 - Attachment is obsolete: true
Attachment #326821 - Flags: review?(joshmoz)
Last of 3 patches. This one removes a whole bunch of Java related code from our samples. No sample needs any Java related code any more (hasn't for years and years).
Attachment #326823 - Flags: review?(joshmoz)
Building with these patches + lates mozilla-central crashes at http://java.com/en/download/installed.jsp?detect=jre&try=1
Attachment #326823 - Flags: review?(joshmoz) → review+
Attachment #326820 - Flags: review?(joshmoz) → review+
(In reply to comment #46)
> Building with these patches + lates mozilla-central crashes at
> http://java.com/en/download/installed.jsp?detect=jre&try=1
> 

WFM

I get:

Verified Java Version
Congratulations!
You have the recommended Java installed (1.6.0_10-ea).

sorry for the bug spam
Strangely I can't reproduce it anymore as well..I could 10 minutes ago and it crashed every single time... :S
(In reply to comment #46)
> Building with these patches + lates mozilla-central crashes at
> http://java.com/en/download/installed.jsp?detect=jre&try=1
> 

Builds with these patches only work with  Java SE 6 Update 10 (1.6.0_10-beta)available from:

https://jdk6.dev.java.net/6u10ea.html

Further, this version comes with both the old style OJI based plugin and the new style plugin.  It is mandatory to use the new style plugin.  Any plugin from any other version of Java or even the OJI plugin from this version will crash as you described.

To double check tht you have the correct plugin, you should visit about:plugins and ensure that under Windows, the only Java related plugins that are active are npdeploytk.dll and npjp2.dll. Under Linux the only Java related plugin should be libnpjp2.so.
Yes Bill it was crashing for me with u10-b25. I am trying to reproduce but cannot get it to crash any more.
It crashes for me if I have a page with flash content open in another tab while loading that page. But I guess this is a separate bug?
I just installed the build brom Bill's site, so far so good here.  
Using Jave 6b25 loaded some java weather satallite maps, Time.gov, and YouTube vid at random, all running at the same time, no crash.  Granted, slow on my old box, but no crash. 

Vista HP SP1
AMD Thunderbird CPU 1.6ghz  1.gig RAM Nvidia 7600GT vid/512meg 

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1a1pre) Gecko/2008062605 Minefield/3.1a1pre Firefox/3.0 ID:2008062605
(In reply to comment #51)
> It crashes for me if I have a page with flash content open in another tab while
> loading that page. But I guess this is a separate bug?
> 

Yes, sounds like a separate bug. Can you please file that with the appropriate steps to reproduce?
Attachment #326820 - Flags: superreview?(jonas)
Attachment #326820 - Flags: superreview?(jonas) → superreview+
First part, moving the JVM auth tools to the plugin code is now checked in.
Attachment #326821 - Flags: review?(joshmoz) → review+
Blocks: 442399
Johnny when do you plan to check-in the remaining patches? Do you wanna have some baking time? Or do they also need sr+?
Status: NEW → ASSIGNED
Attachment #326821 - Flags: ui-review?(jonas)
Attachment #326821 - Flags: superreview?(jonas)
I spoke with Bill today about his test builds, and he indicated in a reply e-mail that the 1st part that was checked in, (comment 54) should 'fix' the no-detection issue.  

I tried todays m-c trunk build, and the java is still not detected.  Is the first checking supposed to fix this issue, or will it take the entire set of patches to correct ?  


i can say the first checkin is not fixing it


i think it needs the other ones
Attachment #326821 - Flags: ui-review?(jonas)
Attachment #326823 - Flags: superreview?(jonas)
The second patch is also required, and for that to compile cleanly the third one is required as well. I'm hoping to get this all checked in next week once I get reviews etc.
Attached patch MOZ_OJI ifdef required (obsolete) — — Splinter Review 
Not possible to compile JVM auth tools without MOZ_OJI
Attachment #328249 - Flags: review?
Comment on attachment 328249 [details] [diff] [review]
MOZ_OJI ifdef required

seems patch util  does not understand changes like "rename from/to..."
Attachment #328249 - Attachment is obsolete: true
Attachment #328249 - Flags: review?
Attachment #326821 - Flags: superreview?(jonas) → superreview+
Attachment #326820 - Attachment description: Move the JVM auth tools from modules/oji to modules/plugins/base → [checked-in] Move the JVM auth tools from modules/oji to modules/plugins/base
Attachment #326823 - Flags: superreview?(jonas) → superreview+
All fixes are now checked in.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → FIXED
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008071119 Minefield/3.1a1pre ID:2008071119

Fine with Java 6 update 7. (not try with update 10 yet)
thanks.
verified
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008071119 Minefield/3.1a1pre ID:2008071119
java 1.6.0_07
WFM in the latest nightly :)

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1a1pre) Gecko/2008071203 Minefield/3.1a1pre ID:2008071203
Status: RESOLVED → VERIFIED
Michael, this bug is for all platforms. So we should need to get it verified on more than Windows before marking it verified. Would be nice for the future. Thanks.

Looks like that Java is detected on OS X but I get hangs everytime I visit a website which contains a Java applet. The regression from this patches is already filed as bug 444881. That's why I cannot verify the fix on OS X.

I believe it's worth to have some tests here?
Flags: in-testsuite?
Target Milestone: --- → mozilla1.9.1a1
Oops sorry guys :(
(In reply to comment #65)
> Michael, this bug is for all platforms. So we should need to get it verified on
> more than Windows before marking it verified. Would be nice for the future.
> Thanks.
> 
> Looks like that Java is detected on OS X but I get hangs everytime I visit a
> website which contains a Java applet. The regression from this patches is
> already filed as bug 444881. That's why I cannot verify the fix on OS X.
> 
> I believe it's worth to have some tests here?

This bug is about making Mozilla 1.9.1 work with the new style JAVA plug-in that as far as I know is only available for Windows and Linux at this time.



This bug is not about whether or not plug-on work correctly, or if they cause hangs and or browser crashes.  It is simply about if the presence of the JAVA plug-in is correctly detected.  With these patches installed it detects the JAVA plug-in on all Operating systems including MAC OSX.

There are 2 remaining and related JAVA plug-in issues which should probably both be filed as new bugs:

1.  With these patches installed not only is the new style JAVA plug-in detected, but the old OJI based plug-in is detected as well.  Attempting to use JAVA applets with the old OJI based based plug-in results in hags and/or browser crashes.  I will probably file such a bug once i get some crash data together.

2.  Under MAC OSX, Java is not a separately installable thing.  It comes bundled with the OS, so the user cannot simply update to the latest version, but is kind of stuck with what comes from Apple for the particular version of OSX the user is running.  Therefore it might be necessary to go back to creating MAC builds with OJI support enabled. Someone who actually has a MAC should probably file this bug (which kind of rules me out).  Such a bug should be filed as a regression from bug 397080 and should also be marked as blocking bug 442399.
(In reply to comment #68)

> 2.  Under MAC OSX, Java is not a separately installable thing.  It comes
> bundled with the OS, so the user cannot simply update to the latest version,
> but is kind of stuck with what comes from Apple for the particular version of
> OSX the user is running.  Therefore it might be necessary to go back to
> creating MAC builds with OJI support enabled. Someone who actually has a MAC
> should probably file this bug (which kind of rules me out).  Such a bug should
> be filed as a regression from bug 397080 and should also be marked as blocking
> bug 442399.
> 

I filed bug 444963 for the OS X issue.
Depends on: 445063
Component: Plug-ins → Java: Live Connect
QA Contact: plugins → live-connect
Keywords: verified1.9.1
Keywords: fixed1.9.1
No longer depends on: 476393
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: