411916 - xpcom-startup fires before component registration

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Matthew Gertner]

Attachment: Simple extension that demonstrates the problem

I'm registering a component that should do stuff on xpcom-startup, so I add an entry to the category manager in the component's registration method. But it looks like this method is being called after xpcom-startup. I believe that xpcom-startup was fired after component registration in Firefox 2.

Comment 1

[Matthew Gertner]

Note that http://mxr.mozilla.org/seamonkey/source/netwerk/test/TestServ.js doesn't seem to get the notification either if you copy it to Firefox's component directory. If you change the topic to app-startup, however, it does get the notification.

Comment 2

[Mike Schroepfer]

Matthew you want to take this?

Comment 3

[Matthew Gertner]

"Want" is a very strong word. :-) I'll take a look and see what I can come up with.

Comment 4

[timeless]

http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/xpcom/build/nsXPComInit.cpp&rev=1.163&mark=585#584
is passing the wrong constant to:
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/xpcom/components/nsCategoryManagerUtils.h&mark=44&rev=1.7#43

it should use:
http://bonsai.mozilla.org/cvsblame.cgi?&file=/mozilla/xpcom/build/nsXPCOM.h&mark=492&rev=1.24#485

Comment 5

[Matthew Gertner]

Attachment: Fixed for timeless's nit

I got this one totally wrong. The problem, apparently, is that app-startup expects the "service," prefix whereas xpcom-startup does not (it assumes the component is a service). I couldn't find any official documentation for the "service," prefix, but if anyone knows where it is located I can update it accordingly since this doesn't appear to be common knowledge. I get the impression that "service," is only used for app-startup.

I guess I misdiagnosed this since I didn't realize that I had to delete compreg.dat and reregister the components when testing. I've tested both my extension and JS component for network with 1.8, the nightly from when I filed the bug and the latest trunk, and all work as expected when the correct contract ID (i.e. sans prefix) is supplied. It might be worth considering getting rid of xpcom-startup at some point since no one seems to think it should be used and it is kind of confusing for it to have different behavior from the same usage of app-startup.

Just so this isn't a total loss, I'm attaching a fix to the issue timeless reported in https://bugzilla.mozilla.org/show_bug.cgi?id=411916#c4.

Comment 6

[Benjamin Smedberg]

Comment on attachment 301897 [details] [diff] [review]
Fixed for timeless's nit

It's the same value, right?

Comment 7

[Matthew Gertner]

(In reply to comment #6)
> (From update of attachment 301897 [details] [diff] [review])
> It's the same value, right?

Yeah.

Comment 8

[Matthew Gertner]

Comment on attachment 301897 [details] [diff] [review]
Fixed for timeless's nit

This shouldn't entail any risk since the constants (old and new) have the same value.

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 301897 [details] [diff] [review]
Fixed for timeless's nit

a1.9=beltzner

Comment 10

[Reed Loden [:reed]]

Checking in xpcom/build/nsXPComInit.cpp;
/cvsroot/mozilla/xpcom/build/nsXPComInit.cpp,v  <--  nsXPComInit.cpp
new revision: 1.261; previous revision: 1.260
done