Closed Bug 354835 Opened 14 years ago Closed 14 years ago

Extension icons/extensions are not registered


(Toolkit :: Add-ons Manager, defect, blocker)

Windows XP
Not set





(Reporter: u88484, Assigned: Biesinger)



(Keywords: regression)


(1 file)

No icons show for extensions on toolbars or in add-ons manager with following errors in error console:

No chrome package registered for chrome://chatzilla/skin/images/logo.png

Started with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060929 Minefield/3.0a1
Summary: Extension icons not registerd → Extension icons not registered
Forgot to mention that I had deleted extension.ini/rdf/cache to allow me to see my updated icon for my extension and upon restart none of my extensions were registered but still show up in the add-ons manager and right-clicking on an extension and selection options (for one of my extensions) froze the add-ons window with 

Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMWindowInternal.focus]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://browser/content/browser.js :: BrowserOpenAddonsMgr :: line 5664"  data: no]
Summary: Extension icons not registered → Extension icons/extensions are not registered
Severity: normal → major
Did all the three extensions.* files get recreated, and if so can you attach them here.

This is a symptom of the chrome not being registered for the extensions so I'd lay a bet on extensions.ini not being right.
All three got recreated but .ini looks like:


and thats it
*** Bug 354843 has been marked as a duplicate of this bug. ***
Can you attach extensions.rdf here please.
maybe regression between 092804 Nightly and 092903 Nightly (Windows Trunk).

<?xml version="1.0"?>
<RDF:RDF xmlns:NS1=""
  <RDF:Seq RDF:about="urn:mozilla:item:root">
    <RDF:li RDF:resource=""/>
    <RDF:li RDF:resource="urn:mozilla:item:{972ce4c6-7e08-4474-a285-3208198ce6fd}"/>
    <RDF:li RDF:resource=""/>
  <RDF:Description RDF:about="urn:mozilla:item:{972ce4c6-7e08-4474-a285-3208198ce6fd}"
                   NS1:name="Firefox (default)"
                   NS1:description="The default theme"
                   NS1:creator="Gerich and Horlander"
                   NS1:contributor="Mozilla Contributors">
    <NS1:type NC:parseType="Integer">4</NS1:type>
    <NS1:targetApplication RDF:resource="rdf:#$rC8FN2"/>
  <RDF:Description RDF:about=""
                   NS1:description="Sends information about program crashes to Mozilla."
    <NS1:type NC:parseType="Integer">2</NS1:type>
    <NS1:targetApplication RDF:resource="rdf:#$OC8FN2"/>
  <RDF:Description RDF:about="rdf:#$PC8FN2"
                   NS1:id="{718e30fb-e89b-41dd-9da7-e25a45638b28}" />
  <RDF:Description RDF:about="rdf:#$rC8FN2"
                   NS1:maxVersion="3.0a1" />
  <RDF:Description RDF:about=""
                   NS1:name="DOM Inspector"
    <NS1:type NC:parseType="Integer">2</NS1:type>
  <RDF:Description RDF:about="rdf:#$OC8FN2"
                   NS1:maxVersion="3.0a1" />


app-global	1159545033	needs-install
app-global	1159545034	needs-install
app-global	{972ce4c6-7e08-4474-a285-3208198ce6fd}	rel%{972ce4c6-7e08-4474-a285-3208198ce6fd}	1159545034	needs-install


Finally got a machine I can test with. The EM is throwing an exception when trying to update extension's version information. This looks to me like something outside the EM has regressed.

ExtensionManager:_finishOperations - failure, catching exception - lineno: 7256 - file: undefined - [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIRDFDataSource.Assert]"  nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)"  location: "JS frame :: file:///C:/Program%20Files/firefox/components/nsExtensionManager.js :: anonymous :: line 7256"  data: no]

Thats at:
Upgrading severity to blocker because even talkback won't work
Severity: major → blocker
hmmm... that regression range doesn't contain anything that I believe could cause this.
(In reply to comment #11)
> hmmm... that regression range doesn't contain anything that I believe could
> cause this.

As true as that may be..
in the Nightly , when I open EM , for both TB and DomI there's a line that tells me "this add-on will be installed after Minefield is restarted".
Needless to say nothing happens after the restart
Backing out those patches and building should help figure out which of those caused this then.
Build identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/2006092916 Minefield/3.0a1

Worked in 2006092904, fails in 2006092916.

Strangely I upgraded from the first to the second using the update mechanism. As I did, I was notified that DOM Inspector would be disabled. Was there a respin of sorts?
(In reply to comment #14)
When you move the DOM inspector to your profile and run a 28 Sep build you can also use it in the latest build.
The problem here is that the install.rdf for DOMi and Talkback are faulty. Specifically the minVersion and maxVersion entries for applications other than Firefox are blank. Either removing the other targetApplications or adding numbers in makes this problem go away.

I don't have any hourlies in between to check but this definitely changed between the nightlies from the 28th and the 29th.

I guess there are two ways to proceed, one is to make the EM a little more resilient to such faulty data (not a bad idea anyway IMO). The other is to figure out what changed with the DOMi and Talkback builds.
I'm not much of a build config guru, but I believe this to be caused by bug 353983. There is now a redeclaration of BOOTSTRAP_core in that appears to override what I assume to be where the version numbers of apps are pulled from.

Im talking a guess that this only hit the nightly because it was of course a clobber build and the hourlies probably still had old defines laying about or something.
Blocks: 353983
(In reply to comment #16)
> The problem here is that the install.rdf for DOMi and Talkback are faulty.
> Specifically the minVersion and maxVersion entries for applications other than
> Firefox are blank. Either removing the other targetApplications or adding
> numbers in makes this problem go away.

do this tip and problem is gone.
The only case where making the em more resilient to invalid required data in the install.rdf is for the build. I'd prefer if the build failed when it provided invalid data than making the em handle invalid data in relation to this bug.
Benjamin, I won't be able to look at this until late next week... could you take a look at what broke with setting versions in the install.rdf's? Thanks
Comment #17 is correct. biesi, can you fix the duplicate setting of BOOTSTRAP_core?
Assignee: nobody → cbiesinger
I don't know if it's useful information but for some reason I'm incapable of reproducing this issue in my own builds.
It may be worth noting that i am having this problem with Thunderbird (20061001 Trunk Nightly) as well as Firefox
Thunderbird trunk nightly started to having this problem with 20060930 build as well.
Attached patch patchSplinter Review
oops. I thought I had fixed this.
Attachment #240956 - Flags: review?(benjamin)
If this isn't in soon (like today), I think we need to close the tree.  We haven't gotten any talkback data on the trunk for quite a few days, so we're not getting any information about whether there are crash regressions.

(I'm presuming that talkback is still being installed for users who have it installed, and we'll start getting talkback data again once this is fixed.)
Comment on attachment 240956 [details] [diff] [review]

Bah, I thought I had reviewed this already.
Attachment #240956 - Flags: review?(benjamin) → review+
Checking in;
/cvsroot/mozilla/,v  <--
new revision: 1.299; previous revision: 1.298
Closed: 14 years ago
Resolution: --- → FIXED
test with windows 2006100321 (Last modified/22:12) with new profile.

I can install an extension but cannot use it.
extension-icon on add-ons manager window does not displayed.

minversion/maxversion in install.rdf, both DOMi and Talkback, is empty.

so nothing seems to be changed.

fixed on next Nightly ?
biesi, could you verify what you checked in is what you wanted to check in? What I see is that you changed the pre-existing BOOTSTRAP_core that has each app's BOOTSTRAP_necko to BOOTSTRAP_necko and left the typo'd BOOTSTRAP_core used for necko as BOOTSTRAP_core.
bah... "has each app's BOOTSTRAP_necko" should read "has each app's version.txt"
What he checked in looks right to me.  Have a look at what the original patch (attachment 239850 [details] [diff] [review]) was doing for {MODULES_NS,MODULES,LOCALES,BOOTSTRAP}_{necko,
core}, and note that one of the changes was missed in the BOOTSTRAP_* changes (what he checked in).
I trust it is the right thing as far as the build goes... the change in this patch does seem a bit strange though. :/
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20061004 Minefield/3.0a1 ID:2006100404 [cairo]

VERIFIED with .zip build
Necko needs these for bootstrap, and core needs everything necko needs. That's why the change looks like it does.
Verified on Linux trunk, too. ->VERIFIED
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.