190144 - New moz installer w/GRE needs to handle upgrade scenario

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect)

Description

[Sean Su]

The new mozilla builds now install GRE in a different directory from the moz
dir.  When this new build is installed ontop of an older mozilla build which has
GRE in the moz dir, problems can arise (such as .dll conflicts).

The Mozilla installer (I don't think this needs to be done by the GRE installer)
needs to handle cleaning up the old GRE that's left over from the previous
mozilla in the moz dir.

Comment 1

[Sean Su]

Attachment: patch v1.0 (ns tree)

Comment 2

[Sean Su]

Attachment: patch v1.0 (moz tree)

Comment 3

[Sean Su]

this bug should be a 1.3b blocker.

Comment 4

[Asa Dotzler [:asa]]

Yes, we need to get this fixed for 1.3beta.

Comment 5

[Samir Gehani]

Comment on attachment 112445 [details] [diff] [review]
patch v1.0 (ns tree)

r=sgehani

Comment 6

[Samir Gehani]

Comment on attachment 112446 [details] [diff] [review]
patch v1.0 (moz tree)

r=sgehani

Comment 7

[Sean Su]

Attachment: patch v1.1 (ns tree)

added more files/dirs to be removed and also changed log comments for removing
files from using "Create Folder: " to "Installing: ".

Comment 8

[Sean Su]

Attachment: patch v1.1 (moz tree)

added more files/dirs to be removed and also changed log comments for removing
files from using "Create Folder: " to "Installing: ".

Comment 9

[Chris Lyon]

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

Comment 10

[Samir Gehani]

Comment on attachment 112640 [details] [diff] [review]
patch v1.1 (ns tree)

r=sgehani

Sean, 
Please comment/document in this bug how you arrived at this list of files to
delete like we discussed.  Thanks.

Comment 11

[Samir Gehani]

Comment on attachment 112641 [details] [diff] [review]
patch v1.1 (moz tree)

r=sgehani

Comment 12

[Sean Su]

The way I arrived at the list of files that need to be deleted was by:
1) installed a pre 01/22 build and a 01/22 build to different dirs
2) performed a directory structure compare

I also did an additional manual/visual verification that the delete file list is
the same as the file list that was moved from the mozilla's packages-win file
list to the gre's  equivalent packages-win file list.

Comment 13

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

Comment on attachment 112641 [details] [diff] [review]
patch v1.1 (moz tree)

rs=sspitzer

Comment 14

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

Comment on attachment 112640 [details] [diff] [review]
patch v1.1 (ns tree)

rs=sspitzer

Comment 15

[Daniel Veditz [:dveditz]]

Comment on attachment 112445 [details] [diff] [review]
patch v1.0 (ns tree)

sr=dveditz

Comment 16

[Daniel Veditz [:dveditz]]

Comment on attachment 112446 [details] [diff] [review]
patch v1.0 (moz tree)

sr=dveditz

This script will be bad if we ever expose the option to install a private GRE
in the browser location -- we'd zap the files that were just installed :-(

Comment 17

[Sean Su]

patches checked in.  marking bug fixed.

Comment 18

[tom.williams]

Attachment: Screenshot of latest bug

I just tried the Win32 2003012804 nightly build and WAS able to get it
installed and running.	However, "My Sidebar" is completely empty and when I
tried to login to Hotmail, Mozilla saw I had stored passwords to login to
Hotmail and displayed an EMPTY dialog for me to choose which id to use and the
buttons on the dialog did NOT work and I had to kill Mozilla to get rid of it.

I will attach a screenshot of what I'm describing.  Is this possibly related or
something else completely?

Peace....

Tom

Comment 19

[Sean Su]

Tom, can you try this:

1) rename the following dirs out of the way (if they exist):
     [program files]\common files\mozilla.org
     [program files]\mozilla.org
     [mozilla dir] (if not in one of the above dirs)
2) reinstall the latest mozilla build.

If you're still seeing the problem, then it's not related to this bug.

If you are no longer seeing the problem, then there's a possibility it's related
to this bug.  I'll need a directory structure listing of the directories listed
above that you renamed out of the way to see which files are not in their right
place.

Comment 20

[tom.williams]

Attachment: Directory list of Mozilla 1.3a files

Ok, I had NO "program files\common files\mozilla.org" directory nor a "program
files\mozilla.org" directory, as I installed Mozilla on my E: drive.

2) reinstall the latest mozilla build.

I renamed e:\mozilla.org to e:\mozilla.org.bak and then installed the latest
mozila build in c:\mozilla.org.  The install went fine and "My Sidebar" WAS
properly populated with the default tabs, etc.	This was much BETTER then when
I installed the latest build in my e:\mozilla.org directory OVER the "official"
1.3a alpha release that I'm running now.

The attached dirlist.txt is from the Mozilla 1.3a (2002121215) build that I'm
using now that DOES work.   Let me know if you need anything else.

Peace....

Comment 21

[tom.williams]

Oh yeah... when I installed the latest build in c:\mozilla.org and it worked,
"My Sidebar" appeared EMPTY at first, and then was properly populated when I
pressed F9 to hide it and then to re-display it.

Sorry for leaving that part out of the other message.  :)

Peace.....

Comment 22

[Sean Su]

wait... I need the dir list (and subdirs: dir /s) from the directory that does
*not* work.  I know what's in the one that does work, cause it's the latest build.

Comment 23

[tom.williams]

Attachment: Directory list of "bad" Mozilla installation

Sorry about that.... :)  Attached is the directory list of the "bad"
(2003012408 Win32 build) Mozilla installation.

Let me know if you need anything else....

Peace.....

Comment 24

[tom.williams]

Ok, as of the 2003021008 Win32 build, the problem I previously reported has been
resolved.  Yay! :)

Peace....

Comment 25

[Grace Bush]

verified