Setup.exe crashes only with 1.4 (Windows 2000)

VERIFIED FIXED

Status

SeaMonkey
Installer
--
critical
VERIFIED FIXED
15 years ago
13 years ago

People

(Reporter: Jerome FILLIERE, Assigned: Sean Su)

Tracking

({crash, stackwanted})

Trunk
x86
Windows 2000
crash, stackwanted

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
Build Identifier: http://ftp.mozilla.org/pub/mozilla/releases/mozilla1.4rc1/mozilla-win32-1.4rc1-installer.exe

When trying to install mozilla-win32-1.4rc1-installer.exe (1.3 previously
installed), the installer crashes just after filling all required information :
a window opened with "SETUP.exe has generated erros and will be closed by
Windows...". But after this windows is displayed the installation starts but
must be incomplete as mozilla doesn't start afterwards. I also had this problem
with 1.4beta but 1.3 installs fine on my host. I must admit that I'm not
administrator on my host, anyway 1.3 installs fine so why 1.4 doesn't ?

Regards,
Jerome.

Reproducible: Always

Steps to Reproduce:
1.run installer
2.
3.

Actual Results:  
SETUP.exe crashes

Expected Results:  
It shouldn't crash ! :)
(Reporter)

Comment 1

15 years ago
Created attachment 124731 [details]
Dump of the crash window

Comment 2

15 years ago
does 1.4RC1 install cleanly when uninstalling previous version before ?
Keywords: crash, stackwanted
(Assignee)

Comment 3

15 years ago
Jerome,

Where are you installing mozilla 1.4rc1 to?
Do you have write access to your [Common files] folder (normally located in
[system drive]\Program Files\Common Files)?
(Reporter)

Comment 4

15 years ago
>does 1.4RC1 install cleanly when uninstalling previous version before ?
no

>Where are you installing mozilla 1.4rc1 to?
to a directory where I have full rights access (previous location of Mozilla1.3)

>Do you have write access to your [Common files] folder (normally located in
>[system drive]\Program Files\Common Files)?
It's right: I don't have access to write in this directory. It would mean that
1.4 uses that directory and 1.3 didn't ?
(Reporter)

Comment 5

15 years ago
I have now write rights in the "common files" directory and installation works
fine. Thanks for your support.

Jerome.
(Reporter)

Comment 6

15 years ago
I would just suggest the error message to be more clear...

Comment 7

15 years ago
-> NEW, + nsbeta1 keyword.

Nominating for fix. Probably happens in XP too, and we don't give a good error.

Confused me for over 45 minutes and 4 install attempts (finally got 1.3.1 working).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: nsbeta1

Comment 8

15 years ago
Created attachment 124871 [details]
dr. watson log when this happens.

There is nothing in the log that explains what is going on.
(Assignee)

Comment 9

15 years ago
obviously it shouldn't crash.  But then if the user doesn't have write access to
[Common Files], what should the solution be?

 1. offer ability to allow user to choose GRE dir
 2. fall back to [mozilla path]\..\GRE
 3. automatically pick some other common dir

any other possible options?
Status: NEW → ASSIGNED

Comment 10

15 years ago
I like option 1.  A dialog could say something like:

"you do not have permissions to install into 
 Common Files. Would you like to install into 
 another location or cancel this install"
Clearly we should get such a user installed if we can, and the logical place is
to the known-writable mozilla install directory. The simplest thing might be
fall back to a private GRE installed into the Mozilla directory. On the other
hand the future of Mozilla is multiple apps so a public GRE is better if possible.

How hard would it be to try in order
  - shared/public: [common files]\mozilla.org\GRE  (current location)
  - shared/public: <mozdir>\..\GRE
  - private: <mozdir>
I could live with a dialog, but i don't like it much and think it will confuse
or annoy a lot of less sophisticated people. The user has already given us
permission to install into <mozdir>, we should be able to put the GRE there
without having to ask permission. Parallel to mozdir as Sean suggests is
slightly dicier, but I'm not sure we should put a shared GRE inside the Mozilla
directory.
(Assignee)

Comment 13

15 years ago
here's another question, for the ns build, where should GRE be installed to if
we go with option 2:
  1. ...[Program files]\Netscape\GRE\1.4...
  2. ...[Program files]\mozilla.org\GRE\1.4...

GRE is a mozilla thing, but it'll be Netscape that will be installing it.  I'm
leaning towards 1. because we should fall back to where the user chose to
install the product.
(Assignee)

Comment 14

15 years ago
Created attachment 124973 [details] [diff] [review]
patch v1.0

This patch will address the crash and the insufficient access for GRE to
install to [common files]\mozilla.org.

When insufficient access is encountered, it will install GRE to:
  [mozilla's path]\GRE\[gre id]

This GRE will be installed in shared/global mode, as opposed to local/private.
(Assignee)

Comment 15

15 years ago
Comment on attachment 124973 [details] [diff] [review]
patch v1.0

seeking r=,sr=
Testing patch with GRE default destination path having only readonly access. 
Write access to default destination path was also tested.

In both cases, the installer and uninstaller worked as expected.

Test cases were done with mozilla.exe on Win2k.

I will do a sanity test with the commercial build as well, but do not expect
problems as the the fix were only with the core setup files.  Config.it files
were not altered for this fix.
Attachment #124973 - Flags: superreview?(dveditz)
Attachment #124973 - Flags: review?(sgehani)
(Assignee)

Comment 16

15 years ago
patch works with the commercial build as well.
(Assignee)

Comment 17

15 years ago
*** Bug 208444 has been marked as a duplicate of this bug. ***
Comment on attachment 124973 [details] [diff] [review]
patch v1.0

>+      assert(CreateDirectoriesAll(aGre->homePath, ADD_TO_UNINSTALL_LOG) == WIZ_OK);

Do the Create for real, not just in debug mode :-)

Looks good to me, but as you explained as we went over this patch the diskspace
checking will return an incorrect result if we end up using this alternate GRE
location. Unfortunately should fix that before checking this in.
Attachment #124973 - Flags: superreview?(dveditz) → superreview-
(Assignee)

Comment 19

15 years ago
Created attachment 125055 [details] [diff] [review]
patch v1.1
Attachment #124973 - Attachment is obsolete: true
(Assignee)

Updated

15 years ago
Attachment #124973 - Attachment is obsolete: false
Attachment #124973 - Flags: review?(sgehani)
(Assignee)

Updated

15 years ago
Attachment #125055 - Flags: review?(dveditz)
Comment on attachment 125055 [details] [diff] [review]
patch v1.1

r/sr=dveditz
Attachment #125055 - Flags: review?(dveditz) → review+
(Assignee)

Comment 21

15 years ago
Comment on attachment 125055 [details] [diff] [review]
patch v1.1

got r=/sr=dveditz
seeking a=

The risk is not great, but somewhat moderate since there's lots of changes.

However, I feel the rewards outweighs the risks.

This bug will affect users who do not have write access to [common files] dir,
which I suspect would be many.

This patch fixes the crash problem and also supports failing to an alternate
path for GRE that is guaranteed to be writable.

I have tested this patch with mozilla and ns under Win2k with write and
non-write access to [common files] dir.  Both install and uninstall works as
expected.

Also made sure that the disk space checking is calculated on the alternate path
(if it was used).
Attachment #125055 - Flags: approval1.4?
(Assignee)

Comment 22

15 years ago
fix checked in to trunk only.
leaving bug open till patch is checked in to branch as well.
a=adt. Please check into branch and add fixed1.4 keyword.

Comment 24

15 years ago
verified it is working on trunk build 2003060608
QA Contact: bugzilla → gbush

Comment 25

15 years ago
verified build 2003060608 is working with write access to Common Files as well
as without write access. 
(Assignee)

Comment 26

15 years ago
Comment on attachment 125055 [details] [diff] [review]
patch v1.1

r=sgehani
(Assignee)

Comment 27

15 years ago
Comment on attachment 125055 [details] [diff] [review]
patch v1.1

making sure r= and sr= are properly set.
got r=sgehani and sr=dveditz
Attachment #125055 - Flags: superreview+
Comment on attachment 125055 [details] [diff] [review]
patch v1.1

a=sspitzer for 1.4
Attachment #125055 - Flags: approval1.4? → approval1.4+
(Assignee)

Comment 29

15 years ago
patch checked in to branch.
bug is now fixed for trunk and branch.
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Keywords: fixed1.4
Resolution: --- → FIXED

Comment 30

15 years ago
*** Bug 208012 has been marked as a duplicate of this bug. ***

Comment 31

15 years ago
verified on branch 20030613
installs with/without write access to Program Files\Common Files
Status: RESOLVED → VERIFIED
Keywords: fixed1.4 → verified1.4

Comment 32

15 years ago
*** Bug 196725 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.