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?

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?

Confirming to bring to the attention of rpallath@eng.sun.com. Gerv

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"

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

*** 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.

*** 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.

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

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.

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

Hi Ed, what's the status of this bug now?

Verified on the branch build (2001-10-09-10-0.9.4)