Using branch build 2002042006 1. Uninstall Java/ old version of N6 2. Install recommended setup type of this build 3. go to www.java.sun.com 4. click on applets/ applet 5. at prompt to download plugin, click on download expected results: Java plugin would be downloaded and I could install actual results: Taken to Netscape.com page that says it cannot find the plugin. I would have to search etc
this works with Linux trunk build on 4/22
that's due to the the new PFS which did not support jre installer.I think Cameron Thomas implemented something just today morning( i see his email).
this has changed a bit now, you will be taken to the netscape plugin finder page (however there is no executable to download from) since it loops back to the java.sun.com page. Greggl is looking at this.
Grace, u mentioned ' this works'. can u enunciate ? Thx!
This is going to be the experience until the server side changes are implemented. If we can't get the server side updated by beta, we can do another change and try to get the Netscape plugin finder pages to point to the binaries that we host. But I would like to try to shoot for the server side to add its new functionality. cc'ing Ray Gerst.
using the Linux recommended setup type installation- I did get the plugin from the ftp.netscape.com site. I tried on Win again with Mozilla (see bug 100393 which really ticks folks off) and now I get into a wonderful circle...click on plugin - go to Netscape.com, click on Java there and go to Java site--click on 'get the plugin' and go to netscape.com. ;-(
Grace, Going around in circles ? :). Hang in there..this should be resolved soon..that's what I heard.
resummarizing now that bug 138500 is fixed..this issue still remains.
what is the timelime for the server side changes? who should own this bug now. 400,000 people have downloaded mozilla RC1 and tons of people are hitting this loop now and blocking us from preemtively finding and fixing java bugs before other big beta releases. let's get some solution in effect as soon as possible.
Keep in mind that the loop issue has been fixed. It is not an ideal fix, which needs to happen on the server side (as mentioned). The current experience takes you to a Netscape.com plugin page that says you need Java, and then that page sends you to java.sun.com, and of course this only applies to people who did not select Java during initial download. There are two ways we can make the experience better. 1.) Have the Netscape.com plug-in page point to the java binary that we host. In order for us to do this, we need to take the jre 1.4 drop we received from Sun, and turn it into a standalone .xpi file - similar to what we did with jre131_02. Then, get this 1.4 standalone up on ftp, then update the N.com database to point to it. We have a meeting with Sun today to address some of the issues with the 1.4 that they gave us. 2.) (Ideal experience) - Update the Plug-in Finder Service itself. This would cut out the Netscape.com plug-in web page, and instead send the user directly to the xpi binary. For this to happen, we again need the jre1.4 in a standalone xpi form, and we need to update the PFS logic. The new PFS logic for all plug-ins, not just Java, won't be ready until right around the time beta ships.
assigning this to gregg
Are we getting anything done before beta? This is a very bad user experience...
Ok - I put in jre1.3.1_02 into the pfs internally. Now the Netscape finder pages will point to the binary. It is still not 1.4.0_01 like it needs to be. This should be ready for beta, but we can't dedicate installer engineers time to this. Work to make a standalone xpi for jre1.4 needs to come after client dependent work is finished. This is on Curt's radar. Click on the url below (inside the Netscape firewall), and this will be the newer experience once we push the new files out. This is enhancement #1 from comment #11. The same experience should occur for linux - except it will point to the linux jre131_02 binary. Shrirang - please go ahead and test this. http://praline.netscape.com/cgi-bin/plug-in_finder.cgi?mimetype=application/x-java-applet
The windows java 131_02 xpi on praline will not install npoji600.dll to Netscape\plugins\ The 1.4 version xpi will need to do this. If user manually deletes the javasoft directory then tries to view a page w/java applets they will not load.
tested on windows and linux candidate buidls (0510): windows: works ok except for what Brent mentioned Linux : Does not work, no plugin gets listed on the netscape page when I visit the above url (gregg's link). Can u check ,Gregg? Thx!
The pfs is working correctly for Windows, we just need to change where it is pointing to...from 1.3.1_02 to 1.4.0_01. It appears as if the logic is set up to handle the same scenario for Linux user agent strings. Ray Gerst or Alex Leykekh will need to look into that.
Sorry, in the last comment I said the opposite of what I meant. It appears as if the server side logic IS NOT set up to handle the User Agent String for Linux. What I mean exactly is the database entry field (SUPPORTED_OS) for Linux isn't talking correctly to the script on the backend. This is what Ray or Alex needs to check on. The product ID on praline is 10030. http://praline.mcom.com/admin/pi/cgi-bin/edit.cgi?productID=10030
Shrirang,I've checked on Linux redhat 7.1 using this build (2002-05-10-15-7/0PR1), when I revisit http://java.sun.com, the applets load fine. I also tried on this bug: 100393,which is this link: http://www.swiftnets.com , it loads fine too.
Patty, this bug is about 'installing' java, not 'loading' applets. Check out gregg's comments above, Thx!
http://praline.netscape.com/cgi-bin/plug-in_finder.cgi?mimetype=application/x-ja va-applet The installer posted here works fine for me with 7.0 (0512) bits on winnt. I even see the npoji600.dll getting installed to my plugins folder. Ran acceptance tests on applets, load fine too. Now, only linux remains...
I'm testing on Win2k and Win98SE 1. Uninstall Java 2. go to Gregg's URL above to launch the java 1.3.1_02 xpi installer Results: the npoji600.dll does not get installed to \plugins\ directory. the plugin sweeping code points to the c:\program files\javasoft\JRE\1.3.1_02\bin\npoji600.dll if user deletes the javasoft directory, applets will not load. pmac witnessed this.
And if the user deletes c:\windows\ their machine won't boot -- I don't understand the point you're making. Does the file get installed somewhere we look for it, such that Java works?
First, this bug (139240) is about the endless loop that a user gets themselves into when they've installed Netscape without Java and try to download jre131_02i.xpi from the plugin finder service via java.sun.com Second, the jre131_02i.xpi posted to Praline will not install/copy the npoji600.dll to the <browser>\plugins\ directory. There is code to "sweep" for the npoji600.dll that gets installed to Javasoft\. However, if user deletes this directory, applets will not load since npoji600.dll is not living in the <browser>\plugins\. User will be required to access the .xpi again. ( see http://bugzilla.mozilla.org/show_bug.cgi?id=144493 regarding this issue )
Brent, If someone manually deletes their /Javasoft directory, they are on their own! Java is gona be seriosly broken for the whole system as many other important files live in /Javasoft, not just np*.dll's. If someone deleted /Netscape, I bet Netscape wouldn't work right either. Instead, use the add/remove programs control panel. Also, JRE 1.4 is located in /Java on my system. We only recently started doing this "sweep". We'll pick the newest one on the system. Older Mozilla based browsers don't do this so the XPI may have to sniff to correctly install (like for 6.2). This bug is only for Windows, but do other plaforms (like OSX) also have problems downloading Java?
Grace, pls verify this . It works now. I just tried with today's branch build on nt ( with PFS ON/OFF)
looks good- tested on Windows 2000 and Java was successfully found and installed
yeah, veriifed fixed. works great now on trunk/branch builds 0812. PFS is also working fine.