205514 - PAC: install problem causes PAC to fail

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect)

Description

[Ernst Ahlers]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507

Mozilla either doesn't load a local proxy configuration file or doesn't evaluate
it correctly. As we're a proxy only site, no external sites are available.

Reproducible: Always

Steps to Reproduce:
1. Install 1.4b over working 1.3 (W2k or XP)
2. next start, Mozilla comes up with dialog box "The connection was refused when
attempting to contact www.mozilla.org"




-- changing the URL from "file:///d|/.../proxy.pac" to
"file:///D:/.../proxy.pac" in Preferences doesn't help

-- reverting to fetch via http://.../proxy.pac doesn't help either

Comment 1

[José Jeria]

*** Bug 205515 has been marked as a duplicate of this bug. ***

Comment 2

[Matthias Versen [:Matti]]

>1. Install 1.4b over working 1.3

Please don't do that because there is a note in the Release notes (AFAIK) that
you shouldn't do that.

Please do this:
Uninstall Mozilla, delete the whole application folder except the plugins
subfolder and reinstall Mozilla.

Comment 3

[Ernst Ahlers]

Bug cause was between screen and keyboard. Right, deleting the old installation
did the trick, thanks for nudging my head.

Comment 4

[Matthias Versen [:Matti]]

no patch = not fixed 

Comment 5

[Matthias Versen [:Matti]]

-> Installer and confirming because this is not the first bug report about this
problem. 

It's always recommend to install in a an empty directory but it should work
without. 

request 1.4 blocking because i don't want to deal with 10dupes every day after 1.4f 

Comment 6

[Sean Su]

So what was the problem with the browser?  Do we know why the browser doesn't
load a local proxy configuration file on an upgrade?

I would be helpful to know what files were left around after an uninstall so
that the installer can make sure to delete it on an "upgrade" scenario.

What would be even better is:
 1) preserving the upgraded dir (where user installed 1.4b over 1.3).
 2) installing 1.4b into new dir.
 3) perform a dir compare between the two dirs.

I have a script that runs on a daily basis that shows me obsolete files between
daily builds since moz 1.0.  The only files that are obsolete and not removed on
an upgrade right now are:
    ...\mozilla\components\l10n.ini
    ...\mozilla\ISimpleDOMDocumentMarshal.dll
    ...\mozilla\ISimpleDOMNodeMarshal.dll

Without such an information, it would be very hard to fix problems like this.

One could argue that the problem could be fixed by simply having the installer
call the uninstaller before installing, but this does not take into account the
hand deletion performed on left over files after an uninstallation.  We would
still need to know which files are left over.

Comment 7

[Darin Fisher]

so, the interface used to talk between necko and the javascript
nsAutoProxyConfig.js component changed between 1.3 and 1.4.  for some reason, if
you install 1.3 over 1.4, some registry in xpcom doesn't get updated correctly.
 cc'ing dougt...

Comment 8

[Darin Fisher]

*** Bug 204604 has been marked as a duplicate of this bug. ***

Comment 9

[Darin Fisher]

a lot of people are experiencing this problem after upgrading from mozilla 1.3.
 i expect it will be a problem for buffy too.  any word on what might be going on?

Comment 10

[Sean Su]

Attachment: patch v1.0

not sure what's wrong with component registration, but I vaguely remember that
the installer deletes the components\*.dat files at install time so everything
starts fresh.

This is no longer being done because xpcom.xpi was the component that did the
cleaning up (and still does).  Since the xpcom.xpi is no longer installed into
the  browser dir, it doesn't cleanup the *.dat from the browser dir, just the
GRE dir.

This patch will take care of cleaning the *.dat from the browser dir.  We'll
need this patch regardless if it fixes this particular problem or not because
it might fix other component registration related problems.

Comment 11

[Darin Fisher]

Comment on attachment 123482 [details] [diff] [review]
patch v1.0

sr=darin (rubber stamp)

Comment 12

[Daniel Veditz [:dveditz]]

Comment on attachment 123482 [details] [diff] [review]
patch v1.0

r=dveditz

Please do the same for the Mac and unix install scripts. Yes, in the native
case we nuke the whole directory, but we'd still like to preserve some
semblance of enabling upgrade XPInstalls. Someday we'd like to take advantage
of the update notification feature.

Comment 13

[Matthias Versen [:Matti]]

*** Bug 205672 has been marked as a duplicate of this bug. ***

Comment 14

[Sean Su]

Attachment: patch v1.1

added one more file to delete (xptitemp.dat) and made same changes to mac and
unix browser.jst files as well.

Comment 15

[Sean Su]

Comment on attachment 123555 [details] [diff] [review]
patch v1.1

moving r=dveditz and rs=darin to this patch.

seeking a=

Comment 16

[(not reading, please use [e-mail] instead)]

Comment on attachment 123555 [details] [diff] [review]
patch v1.1

a=sspitzer

Comment 17

[Sean Su]

patch checked in. closing bug as fixed.

Comment 18

[Matthias Versen [:Matti]]

*** Bug 206560 has been marked as a duplicate of this bug. ***

Comment 19

[Matthias Versen [:Matti]]

*** Bug 206758 has been marked as a duplicate of this bug. ***

Comment 20

[Matthias Versen [:Matti]]

*** Bug 206865 has been marked as a duplicate of this bug. ***

Comment 21

[Matthias Versen [:Matti]]

*** Bug 208133 has been marked as a duplicate of this bug. ***

Comment 22

[Grace Bush]

Ernst,

would you verify that this is fixed?

Comment 23

[Morgan Olsson]

Installed RC1 over 1.4beta (which i did install over 1.3 earlier, and got the 
problem)...
It was set manually to use the proxy, and also RC1 started up with that OK.
Changed to use proxy.pac, and see in the proxy it is using the proxy now OK :)

But, strange and mysterious (for me):
Every time i start Moz1.4RC1 ZoneAlarm pops up and warn Moz is tryig to connect 
to a place outside my trusted zone, for example 195.66.45.66:53, (always :53) 
DNS
Moz then works and is using the proxy wether i block this attempt or not.
So why do Moz try to go outside while it should use the proxy *all* the time?

/Morgan

Comment 24

[Matthias Versen [:Matti]]

*** Bug 208466 has been marked as a duplicate of this bug. ***

Comment 25

[Ernst Ahlers]

> Grace Bush  2003-06-05 10:43
> would you verify that this is fixed?

OK. So now I installed 1.4rc1 over the working 1.4b. Everything worked
flawlessly. As I'm a little short for time, I'd rather not reinstall 1.3 and try
from there.

Thanks for sorting this out. You guys -- err, girls & guys ;) -- are doing a
great job!

Ernst

Comment 26

[Grace Bush]

verified by reporter,  Thanks!

Comment 27

[benc]

*** Bug 210202 has been marked as a duplicate of this bug. ***