If you set a long name to your addon (more than 15chars for example), it seems that some intermediate file of the installation process is being created with a name longer than the maximum supported length on some windows systems. Thus the installation process fails when the zip extractor tries to handle that: Warning: WARN addons.xpi: Failed to install: [Exception... "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIZipReader.extract]" nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)" location: "JS frame :: resource://gre/modules/XPIProvider.jsm :: extractFiles :: line 865" data: no] Source File: resource://gre/modules/XPIProvider.jsm Line: 865 Also this leads to some issues with having deep folder structures, like you can see here: Error: ERROR addons.xpi: extractFiles: failed to create target directory for extraction file = C:\Documents and Settings\Administrator\Application Data\Mozilla\Firefox\Profiles\3c2ucru5.Default User\extensions\staged\jid0-louF1d9B6fCB9aYNBoUJcV7HSHw@jetpack\resources\jid0-louf1d9b6fcb9aynboujcv7hshw-grooveshark-remote-control-data\ui\comfortaa: [Exception... "Component returned failure code: 0x80520011 (NS_ERROR_FILE_NAME_TOO_LONG) [nsIFile.create]" nsresult: "0x80520011 (NS_ERROR_FILE_NAME_TOO_LONG)" location: "JS frame :: resource://gre/modules/XPIProvider.jsm :: extractFiles :: line 849" data: no] Source File: resource://gre/modules/XPIProvider.jsm Line: 849
I think Brian has some plans to fix this.
yeah. The current XPI layout unpacks the XPI into a directory named $JID, and the XPI has top-level directories named $PKGNAME-lib/ or $PKGNAME-data/ , and then the .js filenames go under that. The windows max path length is 256 characters long, and includes all of that plus the full path to the profile's "extensions/" directory. There's a lot of detail in the create_jid() comment in python-lib/cuddlefish/preflight.py (https://github.com/mozilla/addon-sdk/blob/dd9502c49ae90194582e8dc42b11eeb59a6b3dc4/python-lib/cuddlefish/preflight.py#L20). We removed the cryptographic JID from 1.0b5, and the replacement is slightly shorter (27 characters for an 80-bit random JID, while the cryptographic one was 40 characters long), improving the situation a little bit. The main fix for this will be bug 638742, which is to stop unpacking the XPI completely. When that is done, none of the pathnames will matter: they'll all stay safely trapped inside the zipfile. At that point, the name of the XPI file and the length of the profile directory will be the only issues. Secondary fixes, which honestly are more likely to happen *after* bug 638742 if at all, is to drop the 1:1:1 mapping of source filename to zipfile/unpacked name to URI. The names used inside the zipfile (or in the unpacked filenames) could be simple unique counters, as long as they contain the right contents. We want to keep the real filenames inside the URIs, so that errors and exception tracebacks are easy to relate to source code, but with arbitrarily complex resource: protocol mapping functions (currently in harness.js), we could map URI=fullpath -> zipname=1 -> sourcefile=fullpath . Until then, yeah, I guess the best advice is to use shorter package names, use a new non-cryptographic JID, or install Firefox higher up the directory tree so the profile dir's absolute path is shorter.
WONTFIXing in favor of bug 638742.