Closed Bug 37964 Opened 25 years ago Closed 25 years ago

winreg.getValueString test case returns -229 in addition to expected results

Categories

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

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: jimmykenlee, Assigned: dveditz)

Details

(Whiteboard: [nsbeta2+])

Builds: 2000-05-02-09-M16(WIN) 1. From http://jimbob/trigger3.html, click Acceptance drop-down menu and choose a_winreg_createkey_setrootkey and click Trigger case button 2. From http://jimbob/trigger3.html, click Acceptance drop-down menu and choose a_winreg_setvaluestring and click Trigger case button 3. From http://jimbob/trigger3.html, click Acceptance drop-down menu and choose a_winreg_createkey_getvaluestring and click Trigger case button RESULT: The expected value is returned as indicated by install.log. An error -229 is also returned. EXPECTED RESULT: Error -229 is not returned. May be related to Bug 37855. INSTALL.LOG: ------------------------------------------------------------------------------- http://jimbob/jars/a_winreg_createkey_setrootkey.xpi -- 05/02/2000 17:14:36 ------------------------------------------------------------------------------- Acceptance: a_winreg_createkey_setrootkey ----------------------------------------- [1/1] Create Registry Key: HKEY_LOCAL_MACHINE\Software\WinReg Test Key\subkey1\subkey2 [] Install completed successfully Finished Installation 05/02/2000 17:14:36 ------------------------------------------------------------------------------- http://jimbob/jars/a_winreg_setvaluestring.xpi -- 05/02/2000 17:14:42 ------------------------------------------------------------------------------- Acceptance: a_winreg_setvaluestring ----------------------------------- [1/1] Store Registry Value String: HKEY_LOCAL_MACHINE\Software\WinReg Test Key\subkey1\subkey2 [the_name] Install completed successfully Finished Installation 05/02/2000 17:14:42 ------------------------------------------------------------------------------- http://jimbob/jars/a_winreg_getvaluestring.xpi -- 05/02/2000 17:14:50 ------------------------------------------------------------------------------- Acceptance: a_winreg_getvaluestring ----------------------------------- ** getValueString should return 'the_data' = the_data Install **FAILED** with error -229 Finished Installation 05/02/2000 17:14:50 INSTALL SCRIPT: //////////////////////////////////////////////////////////////////////////////// // a_winreg_getvaluestring // // Acceptance test // • Checks that a value is set from the Registry with // getValueString(String subkey, String valname); // // Dependency // • Verify that "a_winreg_setvaluestring.xpi" passes successfully before // triggering a_winreg_getvaluestring.xpi // // ~ XPInstall QA // May 21, 1999 // // March 17, 2000 jimmylee Implement initInstall, performInstall, // cancelInstall // //////////////////////////////////////////////////////////////////////////////// initInstall("Acceptance: a_winreg_getvaluestring", "a_winreg_getvaluestring", "1.2.3.4", 0); var winreg = getWinRegistry(); winreg.setRootKey(winreg.HKEY_LOCAL_MACHINE); valuedata = winreg.getValueString("Software\\WinReg Test Key\\subkey1\\subkey2", "the_name"); logComment("getValueString should return 'the_data' = " + valuedata); if (0 == getLastError()) performInstall(); else cancelInstall();
acceptance test regression from PR1, must fix in PR2
Keywords: nsbeta2
Target Milestone: --- → M16
*** This bug has been marked as a duplicate of 37855 ***
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
These are NOT the same, that would be the same as saying all crashes are the same bug
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
reassign to dan :-) this is a regression
Assignee: cathleen → dveditz
Status: REOPENED → NEW
Putting on [nsbeta2+] radar for beta2 fix.
Whiteboard: [nsbeta2+]
This was just a mis-reported error: in this case there are no queued items to process during finalize, so finalize bailed out too early instead of reporting SUCCESS. Outside the script this lack of reporting was interpreted as failing to finalize or abort the install. I've fixed this particular bug, and in addition added a new return code of -240 to describe situations where the script didn't have an actual JS error (-229) but was simply malformed with respect to properly bracketed install transaction (that is, init - do stuff - perform/cancel)
checked in
Status: NEW → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
Build: 2000-05-24-09-M16(WIN) Back to normal.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.