Last Comment Bug 354835 - Extension icons/extensions are not registered
: Extension icons/extensions are not registered
Status: VERIFIED FIXED
: regression
Product: Toolkit
Classification: Components
Component: Add-ons Manager (show other bugs)
: Trunk
: x86 Windows XP
: -- blocker with 1 vote (vote)
: ---
Assigned To: Christian :Biesinger (don't email me, ping me on IRC)
:
Mentors:
: 354843 (view as bug list)
Depends on:
Blocks: 353983
  Show dependency treegraph
 
Reported: 2006-09-29 08:10 PDT by u88484
Modified: 2008-07-31 04:30 PDT (History)
29 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch (983 bytes, patch)
2006-10-02 10:53 PDT, Christian :Biesinger (don't email me, ping me on IRC)
benjamin: review+
Details | Diff | Splinter Review

Description u88484 2006-09-29 08:10:11 PDT
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
Comment 1 u88484 2006-09-29 08:27:26 PDT
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]
Comment 2 Dave Townsend [:mossop] 2006-09-29 08:47:24 PDT
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.
Comment 3 u88484 2006-09-29 09:03:40 PDT
All three got recreated but .ini looks like:

[ExtensionDirs]
[ThemeDirs]

and thats it
Comment 4 Ria Klaassen (not reading all bugmail) 2006-09-29 09:20:49 PDT
*** Bug 354843 has been marked as a duplicate of this bug. ***
Comment 5 Dave Townsend [:mossop] 2006-09-29 09:58:38 PDT
Can you attach extensions.rdf here please.
Comment 6 pal-moz 2006-09-29 10:00:16 PDT
maybe regression between 092804 Nightly and 092903 Nightly (Windows Trunk).

http://forums.mozillazine.org/viewtopic.php?p=2514680#2514680
http://forums.mozillazine.org/viewtopic.php?p=2514757#2514757
Comment 7 Ria Klaassen (not reading all bugmail) 2006-09-29 10:21:52 PDT
extensions.rdf:

<?xml version="1.0"?>
<RDF:RDF xmlns:NS1="http://www.mozilla.org/2004/em-rdf#"
         xmlns:NC="http://home.netscape.com/NC-rdf#"
         xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <RDF:Seq RDF:about="urn:mozilla:item:root">
    <RDF:li RDF:resource="urn:mozilla:item:inspector@mozilla.org"/>
    <RDF:li RDF:resource="urn:mozilla:item:{972ce4c6-7e08-4474-a285-3208198ce6fd}"/>
    <RDF:li RDF:resource="urn:mozilla:item:talkback@mozilla.org"/>
  </RDF:Seq>
  <RDF:Description RDF:about="urn:mozilla:item:{972ce4c6-7e08-4474-a285-3208198ce6fd}"
                   NS1:installLocation="app-global"
                   NS1:version="2.0"
                   NS1:name="Firefox (default)"
                   NS1:description="The default theme"
                   NS1:creator="Gerich and Horlander"
                   NS1:internalName="classic/1.0"
                   NS1:locked="true"
                   NS1:appManaged="true"
                   NS1:contributor="Mozilla Contributors">
    <NS1:type NC:parseType="Integer">4</NS1:type>
    <NS1:targetApplication RDF:resource="rdf:#$rC8FN2"/>
  </RDF:Description>
  <RDF:Description RDF:about="urn:mozilla:item:talkback@mozilla.org"
                   NS1:installLocation="app-global"
                   NS1:version="3.0a1"
                   NS1:name="Talkback"
                   NS1:description="Sends information about program crashes to Mozilla."
                   NS1:creator="mozilla.org"
                   NS1:homepageURL="http://talkback.mozilla.org/"
                   NS1:appManaged="true">
    <NS1:type NC:parseType="Integer">2</NS1:type>
    <NS1:targetApplication RDF:resource="rdf:#$OC8FN2"/>
  </RDF:Description>
  <RDF:Description RDF:about="rdf:#$PC8FN2"
                   NS1:id="{718e30fb-e89b-41dd-9da7-e25a45638b28}" />
  <RDF:Description RDF:about="rdf:#$rC8FN2"
                   NS1:id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}"
                   NS1:minVersion="3.0a1"
                   NS1:maxVersion="3.0a1" />
  <RDF:Description RDF:about="urn:mozilla:item:inspector@mozilla.org"
                   NS1:name="DOM Inspector"
                   NS1:version="1.9a1"
                   NS1:installLocation="app-global">
    <NS1:type NC:parseType="Integer">2</NS1:type>
  </RDF:Description>
  <RDF:Description RDF:about="rdf:#$OC8FN2"
                   NS1:id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}"
                   NS1:minVersion="3.0a1"
                   NS1:maxVersion="3.0a1" />
</RDF:RDF>



extensions.cache:

app-global	inspector@mozilla.org	rel%inspector@mozilla.org	1159545033	needs-install
app-global	talkback@mozilla.org	rel%talkback@mozilla.org	1159545034	needs-install
app-global	{972ce4c6-7e08-4474-a285-3208198ce6fd}	rel%{972ce4c6-7e08-4474-a285-3208198ce6fd}	1159545034	needs-install


extensions.ini:

[ExtensionDirs]
[ThemeDirs]
Comment 8 Dave Townsend [:mossop] 2006-09-29 10:45:06 PDT
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:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in&rev=1.215&mark=7266#7245
Comment 9 Peter van der Woude [:Peter6] 2006-09-29 14:09:18 PDT
regressionrange

works in the firefox-3.0a1.en-US.win32_20060929_0048pdt build
fails in the firefox-3.0a1.en-US.win32_20060929_0616pdt build (nightly)

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&filetype=match&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-09-29++00%3A16%3A00&maxdate=2006-09-29+04%3A59%3A00&cvsroot=%2Fcvsroot
Comment 10 Peter van der Woude [:Peter6] 2006-09-29 14:30:04 PDT
Upgrading severity to blocker because even talkback won't work
Comment 11 Robert Strong [:rstrong] (use needinfo to contact me) 2006-09-29 14:32:11 PDT
hmmm... that regression range doesn't contain anything that I believe could cause this.
Comment 12 Peter van der Woude [:Peter6] 2006-09-29 14:52:12 PDT
(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
Comment 13 Robert Strong [:rstrong] (use needinfo to contact me) 2006-09-29 15:32:59 PDT
Backing out those patches and building should help figure out which of those caused this then.
Comment 14 Daniel Cater 2006-09-30 02:58:20 PDT
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?
Comment 15 Ria Klaassen (not reading all bugmail) 2006-09-30 03:15:32 PDT
(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.
Comment 16 Dave Townsend [:mossop] 2006-09-30 04:50:00 PDT
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.
Comment 17 Dave Townsend [:mossop] 2006-09-30 05:11:00 PDT
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 client.mk that appears to override what I assume to be where the version numbers of apps are pulled from.

http://lxr.mozilla.org/seamonkey/source/client.mk#208

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.
Comment 18 pal-moz 2006-09-30 06:27:50 PDT
(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.
http://forums.mozillazine.org/viewtopic.php?p=2516246#2516246
Comment 19 Robert Strong [:rstrong] (use needinfo to contact me) 2006-09-30 12:17:07 PDT
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.
Comment 20 Robert Strong [:rstrong] (use needinfo to contact me) 2006-09-30 13:25:39 PDT
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 21 Benjamin Smedberg [:bsmedberg] 2006-09-30 14:23:27 PDT
Comment #17 is correct. biesi, can you fix the duplicate setting of BOOTSTRAP_core?
Comment 22 Dave Townsend [:mossop] 2006-09-30 16:31:11 PDT
I don't know if it's useful information but for some reason I'm incapable of reproducing this issue in my own builds.
Comment 23 Barrie North 2006-10-01 07:44:55 PDT
It may be worth noting that i am having this problem with Thunderbird (20061001 Trunk Nightly) as well as Firefox
Comment 24 Michael Mak 2006-10-01 07:54:58 PDT
Thunderbird trunk nightly started to having this problem with 20060930 build as well.
Comment 25 Christian :Biesinger (don't email me, ping me on IRC) 2006-10-02 10:53:04 PDT
Created attachment 240956 [details] [diff] [review]
patch

oops. I thought I had fixed this.
Comment 26 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2006-10-03 16:28:49 PDT
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 27 Benjamin Smedberg [:bsmedberg] 2006-10-03 17:42:43 PDT
Comment on attachment 240956 [details] [diff] [review]
patch

Bah, I thought I had reviewed this already.
Comment 28 Christian :Biesinger (don't email me, ping me on IRC) 2006-10-03 20:55:58 PDT
Checking in client.mk;
/cvsroot/mozilla/client.mk,v  <--  client.mk
new revision: 1.299; previous revision: 1.298
done
Comment 29 pal-moz 2006-10-03 22:55:46 PDT
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 ?
Comment 30 Robert Strong [:rstrong] (use needinfo to contact me) 2006-10-03 23:49:09 PDT
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.
Comment 31 Robert Strong [:rstrong] (use needinfo to contact me) 2006-10-03 23:50:47 PDT
bah... "has each app's BOOTSTRAP_necko" should read "has each app's version.txt"
Comment 32 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2006-10-03 23:59:24 PDT
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).
Comment 33 Robert Strong [:rstrong] (use needinfo to contact me) 2006-10-04 00:05:54 PDT
I trust it is the right thing as far as the build goes... the change in this patch does seem a bit strange though. :/
Comment 34 Peter van der Woude [:Peter6] 2006-10-04 07:06:11 PDT
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
Comment 35 Christian :Biesinger (don't email me, ping me on IRC) 2006-10-04 09:00:04 PDT
Necko needs these for bootstrap, and core needs everything necko needs. That's why the change looks like it does.
Comment 36 Adam Guthrie 2006-10-04 09:10:41 PDT
Verified on Linux trunk, too. ->VERIFIED

Note You need to log in before you can comment on or make changes to this bug.