Closed Bug 48336 Opened 24 years ago Closed 24 years ago

Proxy default settings in JAVA plugin use wrong browser sets

Categories

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

Product:
Core Graveyard
Component:
Java: OJI
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: oliver.fels, Assigned: edburns)

References

(
URL
)

Details

(Whiteboard: oji_working)

Attachments

(1 file)

cvs diff -u of fix for this bug, first iteration.
1.08 KB, patch
Details | Diff | Splinter Review 
When the proxy settings in the plugin control panel are set to "Use browser
settings", it always seems to use the ones under the browsers manual section.
Even if the browser is set to direct internet connection, the JAVA plugin uses
the proxy entered in the fields below.
Cleaning the fields and restarting the browser solved the problem.
This occured with NS6PR2 and M17 using the actual 1.3.0rc1 oji oji plugin.
Please don't use 1.3.0rc1 with PR1/PR2. This was not meant to have latest OJI 
support. If you want to use Netscape 6 PR with Java, please install Java that 
comes with the Netscape installer, and it will have latest up-to-dated OJI 
support.
*** Bug 49289 has been marked as a duplicate of this bug. ***
It does not matter, whether rc1 is used or the default installation plugin.
Tried several reinstalls of NS6 and M17, removing all traces of previous jre/jdk
installations and Netscape6 and Mozilla browsers included.
Result is always the same.

Oliver, if you clean the fields and restart the browser, and it solves the
problem, then I think it's a prefs problem.  What do you think?
Assignee: drapeau → edburns
Oliver Fels, have you had a chance to look at this again.

Had to do a reinstall of the whole thing, but now it seems the plugin does not
use the browser settings at all.
I will keep an eye on that.

Deinstalled NS6PR2,M17 and all JRE/JDKs.
Reinstalled NS6PR2 with JRE2 support, result:
Plugin always uses a direct connection unless a proxy is entered in the plugin
control panel.
No browser settings working.
This behavior is similar to the Netscape4.x one.This behavior is similar to the
Netscape4.x one.

I suggest the browser<->plugin interaction should undergo some sort of review at
the proxy settings.

Raju, can you please take a look at this?
Assignee: edburns → rpallath
Confirming to bring to the attention of rpallath@eng.sun.com.

Gerv
Status: UNCONFIRMED → NEW
Ever confirmed: true
Will try this out


Tried this on WinNT/98 with FCs JRe bits 1.3.0_01
with nightly mozilla build


If I set Browser to "direct Connection" and 
in the Java Plugin ControlPanel it is set to "Use Browser Settings"

Invoke Browser. Set Trace level to 2 in the Java COnsole.
Load a local applet. I see  trace message
"Conecting to <url> with no proxy"


If I set Browser to "Manual Proxy"
Invoke Browser. Set Trace level to 2 in the Java COnsole.
Load a local applet. I see  trace message
"Connecting to <url> with proxy "webcache-cup:8080"

It seems to be working fine and use the correct  settings as set in the browser.
Marking this "FIXED"
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Added myself to CC list

rpallath, I think you missed what the actual problem was, because you needed to
carry out one more test.

After configuring manual proxy, the next step is to tell the browser to use
direct connection to the internet. That is, repeat your first test, but now
there are entries in the manual proxy fields that should be ignored. You'll find
that the java plugin still attempts to use the proxy settings, even though it
should be using a direct connection to the internet.

This is exactly what I see. I usually use a web proxy, but whenever I work from
home I switch the proxy preference to "direct connection". The java applets
ignore this and still try to use the proxy (which is no longer available, so the
applets fail to work).

Linux 2000111411 using Blackdown plugin (since this is the only one I've been
able to get to work with the nightlies).

This is certainly not fixed, so please reopen.

Hmm.. seems like I missed the last stage.
Actually it indeed is a bug, I seemed to have missed the most vital part of the 
bug.

So Set Plugin ot use Browser Settings
Go to browser, set the Manual Proxy fields.
Now 'Choose direct connections"

In the Java Plugin Console set trace level to 2.
invoke an applet

On the Console you will find a  line 
"Connecting to <url> with proxy "webcache-cup:8080"
when it should have actually indicated "no proxy"

Len , you were right... Reopening the bug
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
*** Bug 62393 has been marked as a duplicate of this bug. ***
This is still happening as of Build 2000121209.  I'm running Linux (Redhat 6.2,
2.2.14).  It took me a long time of testing to figure out this was the problem
of why applets weren't working.  If this bug is not fixed, you may want to
include the workaround (delete manual proxy settings) in the release notes.
*** Bug 59512 has been marked as a duplicate of this bug. ***
*** Bug 63495 has been marked as a duplicate of this bug. ***
I have traced through the plug-in code. There are actually two bugs:

1) Java Plug-in cached the proxy result around and it makes the plug-in to load 
the applet using wrong proxy setting if proxy is changed on-the-fly.
2) The browser cached the proxy result around even if the proxy is changed 
on-the-fly. FindProxyForURL() results cached result.

    I have fixed #1 in the latest JDK beta, but I still see #2.


I'll take this one.
Assignee: rpallath → edburns
Status: REOPENED → NEW
*** Bug 65602 has been marked as a duplicate of this bug. ***
Stanley, FindProxyForUrl does not cache the result.  It asks the prefs service 
each time.
Status: NEW → ASSIGNED
Raju, I don't understand your steps to reproduce this bug.  Can you please 
start from the beginning and include all the steps in one post, so I can 
understand what to do to test this.

In particular, please be clear about which of the two places where you can 
change the proxy policy: the java control panel, and the browser, you are using 
in each step.

Ed
Invoke  Java Plugin Control Panel (Start->Control Panel->Duke icon)
YOu will  a Tabbed Panel show up
Choose the PRoxies Tab.
enable the check box  "User browser settings"
Click on "Apply"
Quit the Control Panel


Invoke  Browser
CLick on Edit->Preferences->Advanced->proxies
Now Choose "Manual  Proxy  configurations"
Enter the value for http-Proxy (webcache-cup  port 8080)
Now choose "Direct connections to the internet"
Click on 'OK"

On the bottom status bar to extreme right, you will the Duke icon.
Click on it.
This will invoke the Java Plugin Console
In the Java Plugin Console set trace level to 2 (just type '2').

invoke  a page with an applet in the Browser URL

On the Java Console you will find a  line
"Connecting to <url> with proxy "webcache-cup:8080"
when it should have actually indicated "no proxy"




Thanks, Raju,

Stanley, you're right about the proxy being cached, but it's not 
FindProxyForURL that's doing the caching.  Somehow, the prefs service isn't 
getting updated.

Ed
Whiteboard: oji_working
I have discovered the cause for the bug on the mozilla side.

If the user has selected "direct connection to the internet", the following 
pref name DOES NOT have a value in the prefs:

"network.proxy.type"

If this pref DOES have a value, then the prefs should be consulted.

Looks pretty straightforward and safe to me. r=a=av.
Asked waterson for sr.
Change to `useDirect = PR_TRUE', and sr=waterson.
You mean for the default value, the first assignment for useDirect?
Sorry, I meant, `use PR_TRUE instead of 1' for the assignment that you added.
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Should M0.8 contain the fix? The problem seems to exist in M0.8 (Build 
Gecko/20010215).
What is the status of the fix ?
Did it find its way into the current releases ?
If so, I´d like to see this bug closed as my reporting email address will be changing in the very near future.
qa->pmac
QA Contact: shrir → pmac
Hi Ed, what's the status of this bug now?
Verified on the branch build (2001-10-09-10-0.9.4)
Status: RESOLVED → VERIFIED
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: