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. :)