27115 - NSMacInstaller (and MozMacInstaller) stops during 'installing files'

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect, P1)

Description

[Grace Bush]

build 2000020908
Steps to reproduce:
1. Run either installer, enter data into installer

Actual results: After download and extraction, installer shows the 'installing 
files with progress pole'  and then stops

Expected result: completion of installation

Comment 1

[Samir Gehani]

Strongly suspect the new AutoRegister call added yesterday. Adding ssu.

Comment 2

[Sean Su]

yes, a call to AutoRegister was added in an attempt to prevent the problem of 
missing or 0 length components.reg (or Component Registry) file.

Added Dan to the CC: list.

Samir, I'll work with you on this.

Comment 3

[Samir Gehani]

My debug build pulled in the wee hours of this morning works. That build has the 
AutoRegister code (which also works). 

Comment 4

[Samir Gehani]

I just pulled and built. My debug installer works fine. We'll wait and see what 
the morning's verification installers' moods are: I'm hoping this is a build 
glitch.

Comment 5

[Samir Gehani]

Today's builds still don't work. Symptoms are that each component appears to 
begin installing but then fails. Logging is not working currently so we don't 
see the error. Building opt to try and debug (yes, you can do that on the Mac).

Comment 6

[Samir Gehani]

Ack! My opt build based on last night's pull worked too! Moving to release 
machines now.

Comment 7

[Samir Gehani]

There appears to be a line ending issue with the install scripts.  JJ's 
install.xpi works fine if I swap in my own simple install.js that installs 
itself.  Moreover, if I unzip his install.xpi, extract his install.js, and 
compress it back into the install.xpi (has normal mac line endings now) then it 
installs fine.  Otherwise, we get SCRIPT_ERROR(-229) as the return value from 
XPI_Install().  It appears that the JS runtime doesn't like the incompatible 
line-endings?  I'm unhappy with this deduction but the solution worked.  This 
theory is also corroborated by the fact that JJ started building on the new G4's 
from the same time this problem surfaced (tools changed etc.).  

Reassiging to JJ to fix the line endings in the install.js's before zipping up 
the .xpis.

Comment 8

[Samir Gehani]

I unzipped the install.xpi on a unix box and found that the extracted install.js 
contained binary data including items that looked like MacCVS resource 
information.

The install.js must not have any resources and furthermore must not be 
AppleSingle encoded otheriwse it is treated as binary by XPInstall and the JS 
runtime.  Also, there were two install.js entries (both identical when 
extracted) in the install.xpi.  This can cause confusion and so we should 
probably ensure only one exists in any given .xpi archive.

So, the line ending speculation was incorrect.  I apologize for being 
misleading.  The issue appears to be with encoding the file -- we shouldn't.  Or 
at the very least, we should get rid of the resource fork before encoding the 
folder in which the install.js resides.

Comment 9

[Samir Gehani]

Problem still occurs on this morning's (noon's)  builds.

Comment 10

[Simon Fraser [no longer active]]

OK, here's how I think we should fix this. Whatever builds .xpi files has to know 

whether, for a particular file type (or file extension), the resource fork is 

important, and it must do the right thing on compressing the files. We know that 

we don't care about resource forks for all text files, including .js files. The 

only files we have that we need resource forks in are the .shlb and executable 

files.



Somehow, the thing that makes .xpi files needs a lookup table to find whether 

resource forks are required for a particular file type. This lookup table should 

be read in from a file checked into the tree.



[Note that some files that are checked in, which are data-only, are missing

files extensions. The WAV files used for AIM sounds are an example. These files 

will need to be renamed.]

Comment 11

[Samir Gehani]

In the short term we should address the issue of removing the res fork from the 
install.js since this is blocking installer testing and verification.  I 
believe the longer term issue is not currently a blocker and hence we should 
address it in a seperate, non-PDT+ bug.  Simon, does this sound reasonable?

Comment 12

[Simon Fraser [no longer active]]

Removing the resource fork from install.js doesn't sound easily automatable. I 
think we need a better solution; after all, it's not hard to do.

Comment 13

[J.J. Enser]

removing the resource fork from install.js can also be easily automated. Before I 
do that, I will take a look back at _working_ installers from last week or so and 
see how these .js file were zipped. It's possible that during the process they 
were loosing their resource fork somewhere along the way and if it's the case, 
find out what's different on the Mac we're now using to build and deliver the 
verification build.
Stay tuned.

Comment 14

[J.J. Enser]

ok, I deserve a blame for this. on the new Mac, Zipit prefs were bad : "Use 
MacBinary when needed" was checked, which explains why we had resource fork after 
extraction... :-(

I will edit today's .xpi's and send mail when installer can be tested again. For 
commercial build, if you already downlaoded NSMacInstaller.sea, you should be 
able to run it again (no need to download this again).

Comment 15

[Grace Bush]

build 2000021413