290312 - Installer fails: Error occurred during installation - Cross-Platform COM: -229 SCRIPT_ERROR

Status: VERIFIED FIXED

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

Description

[Tracy Walker [:tracy]]

Seen on windows Fx branch build 2005-04-13-21-aviary1.0.1

-Setup clean installation environment
-Download installer
-Launch the installer (extraction works fine)
-Proceed through installer to finish; I performed custom install to ensure
Talkback and dev tools are selected for installation.

tested results:
the installer immediatly hangs in the first progress dialog with the following
error message popping up:
Error occurred during installation - Cross-Platform COM: -229 SCRIPT_ERROR

Comment 1

[Steve England [:stevee]]

*** Bug 290314 has been marked as a duplicate of this bug. ***

Comment 2

[Tracy Walker [:tracy]]

This also affects the linux installer for Fx branch build 2005-04-13-22-aviary1.0.1

the error was a [-621] click okay to the error message and it seemed to move,
but then throws the same error for another .xpi.  and so forth. I'll attach the
install log for linux.

Comment 3

[Tracy Walker [:tracy]]

Attachment: install.log of failed install

Comment 4

[Tony Mechelynck [:tonymec]]

The exact same error happens on the Thunderbird aviary installer newly available
today; see Bug 290315

Comment 5

[Tracy Walker [:tracy]]

same problem with 1.0.3 nightly builds this morning 0414

Comment 6

[Chase Phillips]

The 2005-04-13-21-aviary1.0.1 Windows build cycle started before my commit which
was meant to fix Mac build config issues on the branch.  If it had caught my
commit, I would likely believe my check-in was the cause of this problem (though
the patches should only have affected building on the Mac).  As it is, I'm not
sure what caused it.

Comment 7

[:Gavin Sharp [email: [e-mail]]]

Maybe bug 290162? Although it looks like it probably didn't make these builds...

Comment 8

[Tony Mechelynck [:tonymec]]

Attachment: install_status.log and install_wizard.log of failed W32 install

Created attachment: composite of install_status.log and install_wizard.log from
failed install on W32 (install.log contains only data from older, sucessful,
installs).

Comment 9

[Chase Phillips]

The install.log attachment sheds more light on this problem.

Comment 10

[Chase Phillips]

(In reply to comment #7)
> Maybe bug 290162? Although it looks like it probably didn't make these builds...

Yes, that is the likely cause.

Comment 11

[Brendan Eich [:brendan]]

shaver's patching, there are two classes in xpinstall scripts, one for the
global object, one for File, that have the same type of private data.  So
JS_InstanceOf checks for either must be done; JS_GetInstancePrivate checks only
for instanceof one class.

/be

Comment 12

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Attachment: Patch: permit either FileOp or Install classes for the shared methods

The File-static methods were apparently migrated from being just global methods
(cleverly disguised as methods on the Install class object, which is itself
used as a global for these scripts) to also being methods on the File object,
and therefore can be called with either the FileOpClass or InstallClass as the
JSClass of their |this|.  This patch permits either, preferring File to be
named in the error message in case neither class matches the provided this, as
both classes share -- by design -- the same private-data characteristics.

This patch compiles, but I have no idea how to make the installer build
correctly on Linux, so I'm looking for help with that from our intrepid build
and QA team.

Comment 13

[Chase Phillips]

Comment on attachment 180718 [details] [diff] [review]
Patch: permit either FileOp or Install classes for the shared methods

a=chase pending r/sr

Comment 14

[Brendan Eich [:brendan]]

Comment on attachment 180718 [details] [diff] [review]
Patch: permit either FileOp or Install classes for the shared methods

r=brendan, sr=me too if it helps.  Thanks again,

/be

Comment 15

[Chase Phillips]

Comment on attachment 180718 [details] [diff] [review]
Patch: permit either FileOp or Install classes for the shared methods

a=chase for trunk

Comment 16

[Chase Phillips]

Comment on attachment 180718 [details] [diff] [review]
Patch: permit either FileOp or Install classes for the shared methods

Landed on the aviary1.0.1 branch:

Checking in nsJSFile.cpp;
/cvsroot/mozilla/xpinstall/src/nsJSFile.cpp,v  <--  nsJSFile.cpp
new revision: 1.33.42.2; previous revision: 1.33.42.1
done

Comment 17

[Chase Phillips]

blocking-aviary1.0.3+

Comment 18

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Fixed on trunk.

Comment 19

[Brendan Eich [:brendan]]

Don't forget the 1.7 branch.

/be

Comment 20

[Tony Mechelynck [:tonymec]]

(In reply to comment #19)
> Don't forget the 1.7 branch.
> 
> /be

You might also make sure that it gets fixed on Thunderbird (I don't know if the
fix for the Firefox branch will do that automagically or not). See
already-mentioned Bug 290315

Comment 21

[:Gavin Sharp [email: [e-mail]]]

*** Bug 290315 has been marked as a duplicate of this bug. ***

Comment 22

[Daniel Veditz [:dveditz]]

Comment on attachment 180718 [details] [diff] [review]
Patch: permit either FileOp or Install classes for the shared methods

That looks right, r=dveditz

We ought to kill the deprecated forms. Is 1.1 the right time? 1.5?

Comment 23

[Benjamin Smedberg]

1.1 is not the right time. We don't have the documentation infrastructure in
place yet to point to the right stuff.

Comment 24

[Chase Phillips]

blocking1.7.7+

Comment 25

[Chase Phillips]

Comment on attachment 180718 [details] [diff] [review]
Patch: permit either FileOp or Install classes for the shared methods

Landed on the 1.7 branch:

Checking in nsJSFile.cpp;
/cvsroot/mozilla/xpinstall/src/nsJSFile.cpp,v  <--  nsJSFile.cpp
new revision: 1.33.28.2; previous revision: 1.33.28.1
done

Carrying over dveditz's review (lost when I moved the bug from
Firefox->Installer to Core->Installer: XPInstall Engine).

Comment 26

[sairuh (rarely reading bugmail)]

vrfy'd fixed using 2005041412-1.0.3 linux ffox installer bits.

windows ffox build not yet available...

Comment 27

[sairuh (rarely reading bugmail)]

looks good with 2005041413-1.0.3 Firefox bits on Windows XP.

Comment 28

[Tony Mechelynck [:tonymec]]

After going to sleep and back, I still don't see any W32 Thunderbird aviary1.0.1
build posterior to the fix (2005-04-14-10 is only for powerpc-apple-darwin; the
previous TB aviary1.0.1 is 2005-04-14-06, older than the fix; latest-aviary1.0.1
currently has a ThunderbirdSetup.exe with the same datestamp as 2005-04-14-06).
Any ETA known? My guess (based on daily schedule) is approx. 6 hours from now.
Public checking that the fix contagion has indeed reached TB will have to wait
until then.

Best regards,
Tony.

Comment 29

[Steve England [:stevee]]

*** Bug 290457 has been marked as a duplicate of this bug. ***

Comment 30

[Tracy Walker [:tracy]]

the aviary branch Thunderbird build from 0415 on Windows works as well.

marking verified

Comment 31

[L. J. Head]

Trying to run the Win EXE Installer from this post
http://forums.mozillazine.org/viewtopic.php?t=250610

I am for the first time seeing this error.  Can someone re-open?

Comment 32

[Tony Mechelynck [:tonymec]]

(In reply to comment #31)
> Trying to run the Win EXE Installer from this post
> http://forums.mozillazine.org/viewtopic.php?t=250610
> 
> I am for the first time seeing this error.  Can someone re-open?

The link in that post,
http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2005-04-14-09-trunk/ThunderbirdSetup.exe
, is for a single nightly, earlier than the fix. Go to
http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/ and navigate to a
later build.

Best regards,
Tony.

Comment 33

[L. J. Head]

the 4/14 build says it fixed this error and I do not yet see a distribution for
Windows for the 15th.  I am sorry if this is an 'I am new to this issue' but in
that thread mentioned it says that 'these are the bugs fixed with this release'
or something to that effect...so I would expect if downloading a build in that
thread that I would not encounter any of those problems listed as fixed right?

Comment 34

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #33)
> the 4/14 build says it fixed this error and I do not yet see a distribution for
> Windows for the 15th.  I am sorry if this is an 'I am new to this issue' but in
> that thread mentioned it says that 'these are the bugs fixed with this release'
> or something to that effect...so I would expect if downloading a build in that
> thread that I would not encounter any of those problems listed as fixed right?

The thread tracks checkins, and provides links to builds. If it has a link to an
old build, and there is no use posting in this bug any further. This bug has
been verified as fixed by QA testing recent builds. You can get a fixed build of
Thunderbird for Windows at
http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2005-04-15-05-trunk/ .

Comment 35

[Tony Mechelynck [:tonymec]]

(In reply to comment #33)
> the 4/14 build says it fixed this error and I do not yet see a distribution for
> Windows for the 15th.  I am sorry if this is an 'I am new to this issue' but in
> that thread mentioned it says that 'these are the bugs fixed with this release'
> or something to that effect...so I would expect if downloading a build in that
> thread that I would not encounter any of those problems listed as fixed right?

The generic ftp.mozilla.org address connects you to any of the primary Mozilla
mirrors, usually but not necessarily one relatively near you. (I am in Belgium
and it connects me most often to the Belgian, German and Spanish mirrors.) It
takes some time, hours or sometimes days, for an update to be reflected on some
mirrors. You may want to replace ftp.mozilla.org in the URL by
mozilla.osuosl.org -- a university mirror located in Oregon, which has a rather
short lag time compared with some other mirrors.

See http://www.mozilla.org/mirrors.html for a full list of Mozilla mirrors.