<brendan> Deer Park could not install this item because of a failure in Chrome Registration. Please contact the author about this problem. <brendan> I happen to tail -f the stdout/err so see this there alongside that cryptic dialog: <brendan> *** upgradeExtensionChrome: failed for extension talkback@mozilla.org - why not convert to the new chrome.manifest format while you're at it? Failure exception: TypeError: this.metadataDS has no properties <brendan> couple of things about the dialog should be fixed: <brendan> "this item" has no referent in the dialog <brendan> "Chrome Registration" (failure in, even) is meaningless to almost all users, and probably not needed by "the author" (of what? this item, but what's that?) <brendan> do you want a bug? <bsmedberg> that was a dialog, or a JS console message? <brendan> the first line above was in the dialog <brendan> that's it <bsmedberg> yeah, that really sucks as a dialog /be

Assuming that this error message only appears after trying to install an XPI, and that we don't want to bother the user with diagnostic information, I'd suggest keeping the error message short and to the point: "%productShortName was unable to install %extensionName." If a chrome registration error could occur with an already-installed extension (file goes missing?) then we shouldn't use the word "install": "%productShortName was unable to load %extensionName." If we want to include some diagnostic or "how to fix this" information (which is really of questionable value, as extension authors would presumably check the logs, and I somehow doubt that the average user would be able to fix a packaging problem :) then something like: "%productShortName was unable to load %extensionName. It does not appear to be packaged properly."

Quality of implementation -- polish, in a word -- says we should fix this if we can for 1.8b5. I have no idea of the l10n effects, so easy for me to say this. /be

Keep in mind that there was a bug in the EM which has since been fixed that caused this error to occur in this instance and that this error will most likely be seen by ext developers and not the average user. I agree it should be fixed but I'm not entirely sure it needs to be fixed for 1.5. Also, if it was fixed for 1.5 there are several other string bugs that the average user will see that we are holding off on. The approach I'd prefer to take is to have all the strings reviewed in bug 308916 and dumb down all strings like this one where an ext developer is the most likely person to see it and provide the technical details in the js console. Having said that, I'm open to changing them now if it is decided that it is ok to impact i10n at this time.

Per comment 3 we are not going to take this for 1.5/1.8b5

*** Bug 319588 has been marked as a duplicate of this bug. ***

Rob, let's go with: malformedRegistrationMessage=%S was unable to load %extensionName. It does not appear to be packaged properly.

Are the error details captured anywhere? That's going to be basically the first thing that the developer asks the user for when they report the problem, or that the developer herself looks for when she gets that error. (I looked quickly for another bug for that, but didn't find one.)

Also: is a [Error details >] expanding-dialog sort of button too much "bothering the user with diagnostics"? Seems like something that would be helpful in getting the user to the state they desire, which is the installed/updated extension.

As far as I know (see bug 308916) it's logged in the Error Console (nee: JavaScript Console). I think an expanding dialog isn't the best route here, but if it's trivial to add a "More Details" button that opens the Error Console, that might work.

Opening the console doesn't make it clear what the error is; it'll usually be full of crap, and I think our default sort is first > last. Could you explain more about what's not good about the expanding dialog route? I'm looking for a way to get the user the information that whoever helps them resolve their issue will need, even if the user doesn't understand what any of it means.

see comment #3 - this should not be seen by users.

In part due to the fact that we perform several checks to verify an extension it is possible to install an extension we have sections in the code that display these types of messages. An extension that can be installed should never display these messages and the text tends to be somewhat technical as in this case. If we have a regression that triggers the message to be displayed we then get bugs of this nature. What are the choices? Display a simple message with direction to look in the error console, display a somewhat detailed message though we would most likely never display as much as the error console, silently fail, others? I personally think we should keep these messages short and sweet while instructing extension authors to look in the error console for additional info. This keeps us from having to maintain a bunch of different strings for each error condition and there are at least a couple of more that fall into the same category as this one.

This causes a lot of confusion for users. This error is one of the top issues reported on support.mozilla.com after Firefox updates.

What did you search on to find the reports on support.mozilla.com?

bsmedberg was talking about dropping support for contents.rdf, maybe for 1.9.2 so this might just go away.

I'm concerned that the reports on support.mozilla.com are for a bug we don't know about as of yet and reading them may shed some light. The last time we received reports of this it was due to a patch that landed and users should not be seeing this error unless there is something in our code that is broken or extension authors don't bother verifying that their extension install prior to releasing the extension.

There is bug 422213 which hasn't yet got decent STR.

Closing as invalid because this dialog has now been removed from the platform