9.79 KB, image/gif
12.00 KB, text/plain
26.97 KB, patch
|Details | Diff | Splinter Review|
37.93 KB, patch
Sean Su: superreview+
(not reading, please use email@example.com instead): approval1.4+
|Details | Diff | Splinter Review|
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 ! :)
does 1.4RC1 install cleanly when uninstalling previous version before ?
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)?
>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 ?
I have now write rights in the "common files" directory and installation works fine. Thanks for your support. Jerome.
I would just suggest the error message to be more clear...
-> 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).
Created attachment 124871 [details] dr. watson log when this happens. There is nothing in the log that explains what is going on.
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?
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.
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.
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.
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.
patch works with the commercial build as well.
*** 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.
Created attachment 125055 [details] [diff] [review] patch v1.1
Comment on attachment 125055 [details] [diff] [review] patch v1.1 r/sr=dveditz
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).
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.
verified it is working on trunk build 2003060608
verified build 2003060608 is working with write access to Common Files as well as without write access.
Comment on attachment 125055 [details] [diff] [review] patch v1.1 making sure r= and sr= are properly set. got r=sgehani and sr=dveditz
Comment on attachment 125055 [details] [diff] [review] patch v1.1 a=sspitzer for 1.4
patch checked in to branch. bug is now fixed for trunk and branch.
*** Bug 208012 has been marked as a duplicate of this bug. ***
verified on branch 20030613 installs with/without write access to Program Files\Common Files
*** Bug 196725 has been marked as a duplicate of this bug. ***