When bundling an extension in the distribution/extensions directory as an .xpi that has <em:unpack> set to true in its included install.rdf per bug 474289, the xpi is installed to the user profile, but is not unpacked. This can affect the bundled extension from working properly while still appearing to be installed (or it can just bork things). Steps to reproduce: - Install Firefox - Create an <appdir>/distribution/extensions directory - Drop an extension .xpi that requires unpacking into that directory, renaming the .xpi file using it's GUID, e.g. <GUID>.xpi - Launch Firefox with a fresh profile Expected result: - The extension is installed into the profile, unpacked, and loaded Actual result: - The extension is installed into the profile, and loaded, but is not unpacked. I can provide an installer that demonstrates this issue, as well.

This sounds similar to bug 633189, something we also have discovered today. Could it be that we somehow do not correctly register the extensions which have to be installed? This sounds like a blocker for bundled distributions.

This was an intentional limitation of the implementation and can be easily worked around, it will not block the release.

Is the workaround simply to use an unpacked extension in the directory, e.g.: <appdir>/distribution/extensions/<guid>/unpacked-files-go-here ?

Yes, sorry that I missed that comment on the other bug.

(In reply to comment #3) > Is the workaround simply to use an unpacked extension in the directory, e.g.: > > <appdir>/distribution/extensions/<guid>/unpacked-files-go-here > > ? yes

thanks. adds some complexity for repacks, but workable. I wouldn't mind re-visiting post-release, though. thanks folks, appreciate your time.

Unpacked addons are no longer supported.