Trying to download Java plugin takes u back to java page

VERIFIED FIXED

Status

()

Core
Plug-ins
VERIFIED FIXED
16 years ago
16 years ago

People

(Reporter: Grace Bush, Assigned: Gregg Landskov (gone))

Tracking

({regression})

Trunk
x86
Windows 2000
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

16 years ago
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
(Reporter)

Comment 1

16 years ago
adding keywords
Keywords: nsbeta1, regression
(Reporter)

Comment 2

16 years ago
this works with Linux trunk build on 4/22

Comment 3

16 years ago
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).

Comment 4

16 years ago
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.

Comment 5

16 years ago
Grace, u mentioned ' this works'. can u enunciate ? Thx!
(Assignee)

Comment 6

16 years ago
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.
(Reporter)

Comment 7

16 years ago
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. ;-(

Comment 8

16 years ago
Grace, Going around in circles ? :). Hang in there..this should be resolved 
soon..that's what I heard.

Comment 9

16 years ago
resummarizing now that bug 138500 is fixed..this issue still remains.
Summary: 'No plugins found'- is message received when trying to download Java plugin → Trying to download Java plugin takes u back to java page

Comment 10

16 years ago
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.
(Assignee)

Comment 11

16 years ago
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.

Comment 12

16 years ago
assigning this to gregg
Assignee: beppe → greggl

Comment 13

16 years ago
Are we getting anything done before beta? This is a very bad user experience...
(Assignee)

Comment 14

16 years ago
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

Comment 15

16 years ago
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.

Comment 16

16 years ago
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!
(Assignee)

Comment 17

16 years ago
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.
(Assignee)

Comment 18

16 years ago
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

Comment 19

16 years ago
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.

Comment 20

16 years ago
Patty, this bug is about 'installing' java, not 'loading' applets. Check out 
gregg's comments above, Thx!

Comment 21

16 years ago
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...

Comment 22

16 years ago
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?

Comment 24

16 years ago
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 )

Comment 25

16 years ago
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?

Comment 26

16 years ago
Grace, pls verify this . It works now. I just tried with today's branch build on 
nt ( with PFS ON/OFF)
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
(Reporter)

Comment 27

16 years ago
looks good- tested on Windows 2000 and Java was successfully found and installed

Comment 28

16 years ago
yeah, veriifed fixed. works great now on trunk/branch builds 0812. PFS is also 
working fine.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.