The place holder talkback.xpi created by mozilla builds crashes xpinstall. It looks like for every initInstall(), there needs to be a corresponding performInstall(). It currently only calls cancelInstall(). Removing this call altogether still causes the crash. However replacing it with a call to performInstall() fixes it. I'm not sure exactly what's causing this new crash, but since the place holcer talkback.xpi is only a place holder, and there are more urgent fixes out there than this one, I'm going to propose this fix. Patch coming up.
Created attachment 65355 [details] bad xpi file. This is the place holder talkback.xpi file that causes the crash. I'm attaching it here because release eng. replaces this file with the correct copy before uploading it to mozilla.org (meaning there is no way to test this without this attachment). To verify that the crash happens: 1) download a mozilla blob build from mozilla.org 2) run 'mozilla-win32-sea-installer.exe -u' 3) replace the talkback.xpi with the one attached in this bug. 4) run 'setup.exe' and install the default setup type. The crash will happen at the end of the file copying process. Talkback is the last component to be installed. ps. I need this crash problem fixed because it's causing me lots of grief when I try to help debug/verify xpinstall fixes.
InitInstall/cancel is allowed, and certainly shouldn't crash. initInstall() alone should even "work", returning an MALFORMED_INSTALL (-240) error. Is there a bug filed on the crash itself? a workaround is fine for now, but the crash could easily signal a worse problem and shouldn't be swept under the rug. Once the crash is fixed should we undo this workaround? cancelInstall() returns an error code, so if anyone gets this file by mistake they'll know it, with performInstall() people might think the install went fine. On the other hand an error will make the native installer stubs unhappy when mozilla itself installed fine. Periodically we do ship nightly linux builds in this state and get complaints. Maybe the answer is to go ahead and performInstall() so there's a SUCCESS result, but to logComment("****Warning: placeholder talkback.xpi, talkback not installed") and maybe even put up an alert(). TRying an alert may hang or crash, I think I'll have to make xpistub supply an nsIPromptService for that to work. That's platform-specific code, may have to get the native installers to provide it, but they don't know squat about xpcom. bah!
Can't reproduce with 1.7b and the given bad XPI, probably long fixed.
worksforme with windows 1.7 beta. did this workaround get landed? is this still a problem for anyone?
(In reply to comment #6) > worksforme with windows 1.7 beta. did this workaround get landed? is this still > a problem for anyone? Downloaded latest-trunk full installer yesterday 13 April 2004, got the following message during the "Installing Quality feedback Agent" phase... Error: An Installer module talkback.xpi (.xpi) failed to install.
(In reply to comment #7) > Downloaded latest-trunk full installer yesterday 13 April 2004, got the > following message during the "Installing Quality feedback Agent" phase... > > Error: An Installer module talkback.xpi (.xpi) failed to install. just noted this bug is against Win2k OS, the I'm working on Linux Debian
Attachment #65355 - Attachment mime type: application/octet-stream → application/x-xpinstall
*** This bug has been marked as a duplicate of 124525 ***
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE
Component: Installer: XPI Packages → Installer
QA Contact: ktrina → general
You need to log in before you can comment on or make changes to this bug.