Closed Bug 420496 Opened 16 years ago Closed 16 years ago

nsIXPInstallManager reports error code -203 for unsigned package

Categories

(Toolkit Graveyard :: XULRunner, defect)

Product:
Toolkit Graveyard
Component:
XULRunner
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED INVALID

People

(Reporter: georg, Unassigned)

References

Details

(Keywords: dev-doc-complete) 

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.12) Gecko/20080201 SeaMonkey/1.1.8
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b4pre) Gecko/2008022908

nsIXPInstallManager reports error code -203 for unsigned package, but the documentation says that -203 means too many certificates

http://developer.mozilla.org/en/docs/XPInstall_API_Reference:Return_Codes

I don't understand why this error message comes, because the package is not signed and not retrieve via HTTPS but simply retrived via HTTP. There was no such trouble with older versions of XulRunner (1.9a6)

I also do not get a logfile. The error code is reported as third argument of the onStateChange handler in state INSTALL_DONE.

Reproducible: Always



Expected Results:  
I expect the logfile to be written to the root directory of the application (My.app/Contents/Resources/install.log) with detailed information and also I expect the error not to happen, because what the documentation says about the meaning of the error code does not match the situation. There are no certificates and the zip file is not signed nor encrypted.
I'm not sure where that devmo list came from; it's mostly-correct but not quite: see http://mxr.mozilla.org/mozilla/source/xpinstall/src/nsInstall.h for the actual list in the code.

In any case, I'm almost certain that you are trying to install an XPI that is not an extension (i.e. it has an install.js but not an install.rdf). Support for old-style XPIs has been removed. See http://developer.mozilla.org/en/docs/Install.js for details. Please resolve this bug INVALID if this is the cause of the error.
Yes it is a zip file containing an install.js in the root and one or more directories with stuff inside but no install.rdf. So I first have to read your documentation to get a solution to fit the needs ob both old customers needing the install.js to upgrade to an up to date XulRunner inside the application ad the new customers already coming with the up to date XulRunner.

So the problem is probably the change made in http://developer.mozilla.org/en/docs/Install.js and the meaning of -203 in is different than, what the other document said, but this meaning EXECUTION_ERROR might be a result of missing the install.rdf.

So I set this to invalid, and if I don't find a solution, I ask you again.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → INVALID
I'm missing information in the install manifest how to specify where to install all the stuff. I.e. documentation stuff like read_me.txt etc. is to be installed outside the application, because otherwise the user won't see it, other stuff is to be installed at special places inside the application, which is all done by the install.js, but how do I specify all that without the install.js?
When installing an extension you don't get to decide where it is installed. It is unzipped as a unit into the user's profile/extensions/<ID> directory.

What we removed was the ability to install files in arbitrary places via xpinstall. If you need that capability you should use a native installer.
For us this means that a main feature of our application gets broken. We spent weeks to develop our update feature. Any chance to get the old feature in a new interface for XULRunner or as a separate extension that can be easily added?
(In reply to comment #4)
> When installing an extension you don't get to decide where it is installed. It
> is unzipped as a unit into the user's profile/extensions/<ID> directory.
> 
> What we removed was the ability to install files in arbitrary places via
> xpinstall. If you need that capability you should use a native installer.

What we need is excatly that featur, which was given all the time and now has been removed. We use that not just to install extenstion but also to update XulRunner while it is running.

Can you please provide that feature again may be in a new interface or as an optional overlay of the nsIXPInstallManager. We do not use the extension manager, because the packages are customer related. We use this mechanism as a deployment mechanism of individual not public packages, which was working very well also with Windows Vista and Apple Macintosh. There was no problem with the existing interface using the install.js before.



You are welcome to write and ship such a component, using the old xpinstall code if you wish. It will not be included in the Mozilla platform.
Which parts of the XulRunner are that to let me take them to create an overlay?
OS: Mac OS X → All
Hardware: Macintosh → All
Version: unspecified → Trunk
Eric, could you have a look at comment 1? Seems like MDC needs an update.
JFI: The changes were done in bug 406807.
Depends on: 406807
I've fixed the return code list, both to fix the EXECUTION_ERROR being named wrong and to add a couple of missing codes.
Keywords: dev-doc-needed → dev-doc-complete
Georg and Daniel, when reading your comments it looks like that you are searching for the Automatic Update Service (AUS)? Have a look at bug 408190 how it was implemented for the front-end in SeaMonkey2. Probably this could fix your problem.
Status: RESOLVED → VERIFIED
One problem for us is, the installed stuff is personalized it is not public. The server descides from the licence profile stored on the server which packages to deliver or not. Many packages are delivered only to a single customer and they are not stored in the user profile or inside the application but in well known folders in the neigbourghood of the application, where the customer can add also his own self made stuff like template sets.

If I could invoke downloading the zip files and storing them to a file I could implement the API via JavaScript, but using the XHTMLRequest to download a binary like a zip file fails. What I write to disk is damaged. Probably null bytes cause trouble resulting in a saved file that does not match the received data and therfor is useless. So if I know how to invoke a download of binary data like zipped stuff into a file to store it on disk, I could down load the stuff, extract it with the zip reader component and do all the job the nsInstall did until december 2007.
Use nsIDownloader. And please stop spamming this bug.
Hey keep friendly, this issue is not caused by me, but is caused by your side. I already do experiments with the downLoad Manager, but it throws an exception saying no interface. I do something wrong.

Is there anywhere a sample implementation for how to use the nsIDownloader?
Bugzilla is not a place for wandering discussions, nor for technical assistance. Please continue this discussion in mozilla.dev.platform, if desired.

http://mxr.mozilla.org/mozilla/source/netwerk/test/unit/test_bug263127.js#52
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.