JDK-6484949 : The Wrong proxy is derived from Mozilla browsers when there is no entry in prefs.js
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2006-10-23
  • Updated: 2011-03-08
  • Resolved: 2011-03-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7
6u1Fixed 7 b13Fixed
Related Reports
Duplicate :  
Description
J2SE Version (please include all output from java -version flag):
  java version "1.6.0-rc"
  Java(TM) SE Runtime Environment (build 1.6.0-rc-b97)
  Java HotSpot(TM) Client VM (build 1.6.0-rc-b97, mixed mode)

Does this problem occur on J2SE 1.3, 1.4.x or 1.5?  Yes / No (pick one)
  No, it works fine with Tiger.

Operating System Configuration Information (be specific):
  Win_xp

Bug Description:

 Invoking "javaws.exe http://profiler.netbeans.org/download/temp/HeapWalkerPreview.jnlp"
 for both Tiger and Mustang JDKs. In the former's case the application loads
 up fine. In the latter's case, you will get the attached screenshot. Now, there
 are two bugs at play here:

  1) shouldn't be getting this authentication dialog at all since it
     works fine with Tiger.

  2) When hit CANCEL, Mustang repeatedly brings it back up 20 times
     before finally aborting the process. This is *very* annoying. I
     understand it retrying 20 times on failed authentication but when the
     user explicitly hits CANCEL it should know to abort right away.


Steps to Reproduce (be specific):
  1. find prefs_good.js and prefs_bad.js.
  2. rename prefs_good.js as prefs.js file, Webstart works fine. If use prefs_bad.js
     instead, it fails with authentication dialog. 

     The only difference is that prefs_good.js explicitly states:

         user_pref("network.proxy.type", 0);

     whereas prefs_bad.js does not set this key to anything. Now, the
     default value for "network.proxy.type" is zero, so it is fairly clear
     that what is going on is that Webstart mistakenly believes the default
     value is something other than zero. 

  You should be able to drop in prefs_bad.js into your own firefox installation 
  to verify this.
Same report from another CAP member:

J2SE Version (please include all output from java -version flag):
java version "1.6.0_01-ea"
Java(TM) SE Runtime Environment (build 1.6.0_01-ea-b02)
Java HotSpot(TM) Client VM (build 1.6.0_01-ea-b02, mixed mode, sharing)


Does this problem occur on J2SE 1.4.x or 5.0.x ?  Yes / No (pick one)
No


Operating System Configuration Information (be specific):
Windows XP PRO SP2
IE 7.0
FireFox 2.0.0.1
FireFox extension QuickProxy 2006.10.09

Hardware Configuration Information (be specific):
Sony VIAO laptop 2.8 Gz
1.25 GB RAM
(Also reproducible with a different configuration)


Bug Description:
The fix to this issue (what I believe is 6484949) seems incomplete.
Using a popular Firefox extension called QuickProxy, the settings are still wrong.  QuickProxy installs a button on the Firefox
status bar to quickly turn on and off the proxy.  It seems that webstart does not read the current proxy settings when they are manipulated in this manner.

To reproduce, run the test program.
-- The proxy will be reported correctly
Using QuickProxy, change the proxy status
Run the test program again.
-- The proxy will not report the current status
Run the test program again.
-- The proxy will still not report the current status
In Firefox, go to Tools -> Options and then immediately press OK
Run the test program again.
-- The proxy will report the correct proxy status

Original Report
----------------
When webstart is told to "Use browser settings", it seems to grab those from Firefox2, regardless of whether or not it is 
launched by IE 7 or Firefox.

What is worse, it seems to ignore the "Direct Connection" option in FireFox and returns the proxy server anyway.  

To test this, I enabled the proxy in Firefox, typed in a bogus proxy server, and then switched back to direct connection.  
The proxy in the console gave the bogus proxy address when launched from IE or Firefox.

I did this cycle a second time, using a different bogus proxy IP and again got the bogus proxy I had just entered.


Steps to Reproduce (be specific):
See attached

The jar file will need to be signed.  There is a place for this in the build.xml file, but I am not sending our
 certificate. :)

Comments
WORK AROUND There are several workaround for this problem: 1. When you select direct connection in Firefox/Mozilla, don't specify proxy info inside box. 2. If you specify info inside box, don't use the authentication proxy server, a regular proxy server should be fine because JWS will fail over to Direct if it unsuccessfully. 3. Setup IE as your default browser instead of Firefox/Mozilla.
26-10-2006

EVALUATION The problem is that we treat prefs.js doesn't include line: user_pref("network.proxy.type", 0); As manual proxy setting instead of Direct connection. It works in Tiger because JWS will already look for Proxy info from IE browser setting, not Mozilla or Firefox. There are several workaround for this problem: 1. When you select direct connection in Firefox/Mozilla, don't specify proxy info inside box. 2. If you specify info inside box, don't use the authentication proxy server, a regular proxy server should be fine because JWS will fail over to Direct if it unsuccessfully. 3. Setup IE as your default browser instead of Firefox/Mozilla. This bug will be fixed in Dolphin and Mustang update release.
26-10-2006

EVALUATION Answer from the submitter: >1. Which browser to use? Firefox? which version Firefox 1.5.0.7 >2. Which platform and OS WinXP sp2 >3. What is user select in connection window? set to "direct connection to the internet" using the UI then prefs.js does not contain: user_pref("network.proxy.type", 0) It is the default so they choose to omit it. >Not 0, how user get value 0? Without this line in prefs.js (which user >mentioned in prefs_bad.js), the browser won't even connect to internet >if you are inside firewall. "0" denotes "direct connection to the internet" and it is the default value so whether it is explicitly stated or not the expected behavior should be the same. >Please ask user to launch JWS application from Firefox browser, if you launch JWS >application from command line, then it will look for the default browser proxy >setting, it maybe Firefox or Mozilla, if you have a bad proxy setting, then it will >fail. The user is launching JWS directly from within FireFox and need running completely outside the firewall with FireFox set to "direct connection to the internet" ps. if explicitly add user_pref("network.proxy.type", 0) into prefs.js by hand, you can clearly see that JWS behaves differently than when prefs.js omits it. This, in its own right, completely contradicts the expected behavior as mentioned in the mozillazine.org article and indicates a JWS bug. I think JWS is mistakenly thinking that if network.proxy.type is not explicitly defined then it means to use a proxy.
24-10-2006

EVALUATION I need more info from customer in order to reproduce this bug: 1. Which browser to use? Firefox? which version (I am using Firefox 1.5.0.7). 2. Which platform and OS (I am using Window XP Professional) prefs.js is a property file generated by Firefox, user should't change it and only should apply changes in options window, which will generated this file automatically. What is user select in connection window? I assume it use: "Manual proxy configuration" which will automatically generated: user_pref("network.proxy.type", 1) Not 0, how user get value 0? Without this line in prefs.js (which user mentioned in prefs_bad.js), the browser won't even connect to internet if you are inside firewall. Please ask user to launch JWS application from Firefox browser, if you launch JWS application from command line, then it will look for the default browser proxy setting, it maybe Firefox or Mozilla, if you have a bad proxy setting, then it will fail.
23-10-2006

EVALUATION The webstart link: http://profiler.netbeans.org/download/temp/HeapWalkerPreview.jnlp not available anymore, please provide another JWS application to reproduce this bug.
23-10-2006