210202 - Auto-installing into new folder breaks proxy autoconfig.

Status: RESOLVED DUPLICATE of bug 205514

(SeaMonkey :: Installer, defect)

Description

[Ian Graham]

User-Agent:       Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; H010818; YComp 5.0.2.4)
Build Identifier: http://mozilla.org/releases/index.html#1.4rc2  (Talkback enabled Full Installer )

Initial conditions: I had local installed versions of Mozilla 1.3 and Mozilla 
1.4b, installed into the folders:

...\mozilla.org\mozilla
...\mozilla.org\mozilla1.4b

I then downloaded 1.4RC2 (Talkback enabled full installer) and ran the 
installer -- choosing to install the application into a new folder: 

...\mozilla.org\mozilla1.4rc2

Installation went fine -- but upon startup, the browser couldn't find the proxy 
autoconfiguration details, and I couldn't connect through my firewall.

I next used Windows 'uninstall' to remove the 1.3 and 1.4b versions (both had 
been 'full installer' versions), but this did not resolve the problem.

The problem was fixed by physically removing the 

...\mozilla.org\mozilla1.4b

folder. When I did that, the RC2 version was able to locate and load the proxy 
config data.


Reproducible: Always

Steps to Reproduce:
1. see above..
2.
3.

Comment 1

[Matthias Versen [:Matti]]

It's known that 1.4b breaks PAC but how could it break a Mozilla installed in a
different folder ?

Comment 2

[Ian Graham]

I was suprised myself ... I previously encountered the PAC problem with the 
1.4b install (which I had installed on top of 1.3), and consequently had to re-
install 1.4b in a new folder.  I thought I'd avoid that problem this time, by 
also installing 1.4RC2 in a new folder.  

So, the problem reported here may have been a side-effect of a rather long 
sequence of installs:

1) Install 1.3 
2) Install 1.4b on top of 1.3 (same folder)
3) Re-install 1.4b in a new folder
4) Install 1.4RC2 in a new folder

And I'm sure there's a 'Install 1.2' back in the sequence somewhere..... 
Needless to say, it's a bit hard to reproduce .... :-( 

Comment 3

[benc]

This is because the installer sets the network.proxy.type to "manual" in
all-proxy.js, which lives in the default/prefs folder of the application
installation.

So the problem follows the installed version. See bug 39015 and bug 84732.

Comment 4

[benc]

More likely this...

*** This bug has been marked as a duplicate of 205514 ***