40518 - getFolder: -229 unexpectedly returned when platform specific target folder used on another platform

Status: VERIFIED DUPLICATE of bug 37855

(Core Graveyard :: Installer: XPInstall Engine, defect, P3)

Description

[Jimmy Lee]

Build: 2000-05-24-09-M16(WIN), 2000-05-24-08-M16(LINUX), Not test on Mac yet

1. From Windows, open http://jimbob/trigger3.html, click Acceptance drop-down 
   and choose any Mac or Unix specific test case using getFolder (ie, 
   a_getfolder_1_macctrlpanel, a_getfolder_1_macextension, 
   a_getfolder_2_macfonts, a_getfolder_1_unixlocal, a_getfolder_2_unixlib, etc)
2. Click Trigger case button
3. Click Ok button from confirmation dialog

RESULT:
Install.log shows -229.  If the test case is triggered for the platform that the 
target is intended to support, then no error occurs.

EXPECTED RESULT:
We should either ignore and proceed through the remainder of the install script, 
or we should capture the problem to a unique XPInstall error.

EXAMPLE INSTALL.LOG:
-------------------------------------------------------------------------------
http://jimbob/jars/a_getfolder_2_macdocuments.xpi  --  05/24/2000 17:37:41
-------------------------------------------------------------------------------

     Acceptance: a_getfolder_2_macdocuments
     --------------------------------------


     Install **FAILED** with error -229

     Install **FAILED** with error -229
     Finished Installation  05/24/2000 17:37:41

NOTE:
Similar behavior is observed from Linux when triggering Mac test cases 
using Mac target folders for getFolder().  The assumption is that the Mac would 
behave the same if it would trigger Window or Unix specific target folder forms 
of getFolder().

Comment 1

[Daniel Veditz [:dveditz]]

Platform-specific getFolder() should return null, just like any erroneous input 
to getFolder().  This script might still abort (-229) if it does stupid things 
with the returned null, but the getFolder() itself should not abort the script. 
That is,

f = getFolder("garbage");
f.foo = "dynamic subclassing :-)";

would abort on the f.foo line.

Comment 2

[Jimmy Lee]

Build: 2000-05-24-09-M16(WIN), 2000-05-24-08-M16(LINUX)

The -229 error occurs even if the install script just contructs an object.  Both 
Linux and Windows returned the error.  My assumption is that the Mac would not 
return this error, but we are currently blocked on the Mac.

INSTALL.LOG:
-------------------------------------------------------------------------------
http://jimbob/jars/mactrash_only.xpi  --  05/25/2000 12:02:06
-------------------------------------------------------------------------------

     Functional: mactrash_only
     -------------------------


     Install **FAILED** with error -229

     Install **FAILED** with error -229
     Finished Installation  05/25/2000 12:02:07

INSTALL SCRIPT:
////////////////////////////////////////////////////////////////////////////////
// mactrash_only
// 
// Functional test
// 	• Checks for any errors returned if script constructs object only for
//        platform-specific target folder
//
// ~ XPInstall QA
//   May 25, 2000
//
////////////////////////////////////////////////////////////////////////////////

regName = "mactrash_only";
jarSrc = "smrtupdt.txt";
var vi = "1.0.1.21";

initInstall("Functional: mactrash_only", regName, vi, 0);
f = getFolder("Mac Trash");

if (0 == getLastError())
	performInstall();
else
	cancelInstall();

Comment 3

[Samir Gehani]

Well, we know that Mac doesn't return this error for the "Mac Desktop" target 
since browser.xpi in the daily builds uses this target.  It would be easy enough 
to test this "Mac Trash" .xpi from the installer (but probably a low priority).

Comment 4

[Daniel Veditz [:dveditz]]

I think this is just a special case of bug 37855

*** This bug has been marked as a duplicate of 37855 ***

Comment 5

[Jimmy Lee]

Bug 37855 has been marked Verified.  Marking this dupe Verified.