User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050502 Firefox/1.0+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050502 Firefox/1.0+ When trying to install an extensions with a malformed install.rdf file, the following error appeared: Firefox could not install this item because "install-qx4..rdf" (provided by the item) is not well-formed or does not exist. Please contact the author about this problem. It just might make a little more sense if the filename given was correct. Reproducible: Always Steps to Reproduce:

Steps to Reproduce: (e.g.) replace: <?xml version="1.0"?> with: <?xml version="1.0"> in install.rdf Actually the given filename is correct because firefox extracts install.rdf from the xpi to the temp dir giving it install-[3-random-chars].rdf filename. http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in&rev=1.95&root=/cvsroot&mark=465-484#464 I would say that this bug is invalid but on the other hand this error message might be tweaked a little. FYI There is other bug concerning malformed install.rdf's - Bug 251379 .

confirming, minor display issue.

Instead of displaying the file name it may be more appropriate to just use the term "install manifest".

Sounds good to me. Hides the details from the user but still provides enough info to understand the problem.

We'll probably look into cleaning this up along with the other EM strings for 2.0

Rob, based on your suggestion to me in email, and assuming this sort of thing really only happens rarely and during testing (ie: it's the sort of problem that's wrapped up before someone ships an extension), I'd suggest: %S was unable to load %extensionName. The install manifest appears to either be poorly-formed or missing. which shoots for some consistency with bug 302527 comment 6.

Mike, regretfully this is a catch 22... if the install.rdf is malformed we are unable to get the extension name which is located inside of the install.rdf

I came across this bug while looking for bugs related to a different problem. I will add in my $0.02 here because I did run into this while debugging an extension on a platform I never use. OS2. eComstation is distributing a live cd called democd. It foolishly sets the temp vars up to point to a fat partition in a ram drive. (Defaults to Z:) The temp copy of install.rdf, exceeds the filesystem's naming length limit, so install-[3 random chars].rdf never succeeds. Yes... I tracked the error down to what type of partition ecomstation had tmp=, temp=, tmpdir= pointing to. This error was blamed on the extension, which is really misleading. The double dot in the name given back to the user, was even more misleading. That gives the appearance of some error in gluing filename parts together inside firefox. There are a few ways to handle this more gracefully. It was not the extension that was to blame in this instance. The EM should use operating system calls to generate temp files in the best case.

I realize ecomstation is more at fault here, but the error msg is also having nothing to do with the problem at hand.

(In reply to comment #7) > if the install.rdf is malformed we are unable to get the extension name But we could use the XPI filename: "... because the installation manifest (install.rdf) within my_funky_extension.xpi is malformed ..."

This is fixed with the extension manager rewrite.

(In reply to comment #11) > This is fixed with the extension manager rewrite. Well, i wouldn't call it fixed because now we don't show anything in the message list. There is no indication that the installation has been failed.

(In reply to comment #12) > (In reply to comment #11) > > This is fixed with the extension manager rewrite. > > Well, i wouldn't call it fixed because now we don't show anything in the > message list. There is no indication that the installation has been failed. That isn't true, bug 552965 means we show errors.

I have modified the install.rdf and removed the '?' from the first line. The extension doesn't get installed but also no error message is shown.

The missing error message will be handled by bug 577048. Closing bug again because the underlying issue has been fixed.

Don't think it is worth testing this, the localised messages no longer include a filename part so this should be fine.