296561 - Make it possible to access nsIXULRuntime during xpcom-startup event

Status: RESOLVED FIXED

(Toolkit Graveyard :: XULRunner, enhancement, P2)

Description

[Darin Fisher]

Make it possible to access nsIXULRuntime during xpcom-startup event

Right now, one cannot access nsIXULRuntime or nsIXULAppInfo during the
xpcom-startup event, which fires before NS_InitXPCOM2 returns.

Since these interfaces expose information about the runtime, we probably want to
ensure that they are available sooner rather than later.  I realize that people
could defer to the app-startup event, but a lot of documentation out there
mentions xpcom-startup.

We could probably solve this bug easily by leveraging the static component loader.

Comment 1

[Benjamin Smedberg]

Attachment: NS_InitXPCOM3, rev. 1

This patch works on windows with dynamic and static builds of ffox/tbird and
with dynamic/static/libxul builds of xulrunner. It also fixes the embedding
clients built on Windows. It does not fix seamonkey static build, and I will
attach a separate patch for the camino static build.

Comment 2

[Benjamin Smedberg]

Comment on attachment 186347 [details] [diff] [review]
NS_InitXPCOM3, rev. 1

Dougt, I've burndened darin with a lot of reviews recently, can you take on
superreviewing this?

Comment 3

[Darin Fisher]

Please specify whether static components specified via this interface are loaded
before or after dynamic components.  I recall observing that static components
are currently registered after dynamic components making it difficult to
override a static component.  I think it should be the other way around.

Comment 4

[Benjamin Smedberg]

I would be happy to switch the native and static component loader
(nsComponentManagerUtils.cpp#3193 and #3197), but I'm leery about
frozen-documenting that before we come up with a better XPCOM override mechanism
in general.

Comment 5

[Darin Fisher]

Hrm... I think we should specify the order since it would be a natural question
of anyone calling NS_InitXPCOM3.  We could also specify that it is not
specified.  Either way, we need to say something about it.

Comment 6

[Benjamin Smedberg]

I'm happy enough to document that the static components come first, as long as
we don't specify the relative ordering of native/JS/python/whatever components.

Comment 7

[Darin Fisher]

That sounds fine to me.

Comment 8

[Benjamin Smedberg]

Attachment: NS_InitXPCOM3, rev. 2

This changes the autoreg order to static -> dynamic -> others, but only
documents static -> everything else as I plan to change the "everything else"
situation a little bit in the 1.9 timeframe (nsIComponentLoader ->
nsIModuleLoader, but not filed yet).

It also makes sure that the static components are registered in the order they
appear in the NS_InitXPCOM3 list. This means that static camino and other
embedders can reliably override core gecko components.

Comment 9

[Doug Turner (:dougt)]

Comment on attachment 186396 [details] [diff] [review]
NS_InitXPCOM3, rev. 2

Alot cooler then the _BUILD_STATIC_BIN #define we were using!

A few general q's:

Why are you removing the ablity to disable the static build?
Why are you moving the nsGetModuleProc into nsXPCOM.h.	It is already defined
in nsModule.h:53.
Can you avoid NS_InitXPCOM3 by adding a function that can set the
nsStaticModuleInfo data before init is called?



Could you fix up the spelling error(s) "initialisation" in nsXPCOM.h, plz.

Comment 10

[Benjamin Smedberg]

> Why are you removing the ablity to disable the static build?

Because the static loader is now part of the frozen XPCOM API, and I haven't
found any consumers who really need to disable it (minimo uses it, and that's
the only real consumer I'm worried about WRT codesize).

> Why are you moving the nsGetModuleProc into nsXPCOM.h.	It is already defined
> in nsModule.h:53.

nsModule.h is not a frozen header, at least as far as I can tell, and I need the
function prototype declaration for the structure.

> Can you avoid NS_InitXPCOM3 by adding a function that can set the
> nsStaticModuleInfo data before init is called?

I could, but I don't think it's a good idea. I don't want multiple callers to
start overriding static component lists or other badness.

> Could you fix up the spelling error(s) "initialisation" in nsXPCOM.h, plz.

Damn yankees ;-)

Comment 11

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 186396 [details] [diff] [review]
NS_InitXPCOM3, rev. 2

+ * Initialises XPCOM with static components. You must call this method
+ * before proceeding to use xpcom. 

I have the choice between NS_InitXPCOM2 and 3, right? maybe the comment should
make that a bit more clear...

Comment 12

[Benjamin Smedberg]

biesi: suggest wording?

Comment 13

[Christian :Biesinger (don't email me, ping me on IRC)]

"One of the NS_InitXPCOM methods must be called before proceeding to use XPCOM."

Comment 14

[Mike Shaver (:shaver emeritus)]

Comment on attachment 186396 [details] [diff] [review]
NS_InitXPCOM3, rev. 2

I'll try to get to this review this week; it's a big'un.

Comment 15

[Mike Shaver (:shaver emeritus)]

Comment on attachment 186396 [details] [diff] [review]
NS_InitXPCOM3, rev. 2

r=shaver.  It'd be nice if there was a macro outside of nsIGenericFactory.h
that let people get the right calling convention on their NSGetModule impl, but
it's no big deal.

Comment 16

[Benjamin Smedberg]

dougt, ping? An important Firefox extension author wants this badly.

Comment 17

[Darin Fisher]

Comment on attachment 186396 [details] [diff] [review]
NS_InitXPCOM3, rev. 2

>Index: xpcom/build/nsXPCOM.h

>+typedef nsresult (PR_CALLBACK *nsGetModuleProc)(nsIComponentManager *aCompMgr,
>+                                                nsIFile* location,
>+                                                nsIModule** return_cobj);

Should this use NS_CALLBACK instead?  I'm not sure.  We don't seem to be
very consistent in our use of cdecl vs stdcall.

Comment 18

[Benjamin Smedberg]

NSGetModule is very unfortunately *not* stdcall on windows, it is cdecl.

Comment 19

[Benjamin Smedberg]

Comment on attachment 186396 [details] [diff] [review]
NS_InitXPCOM3, rev. 2

I'm going to re-mark dougt's review based on the fact that we can't use
NS_CALLBACK because it would change our frozen-by-real-life cdecl NSGetModule
signature, and requesting approval. This is unlikely to break the toolkit apps
or camino, which have been tested.

Comment 20

[Benjamin Smedberg]

Attachment: Final patch for commit

This is the final patch committed, there were some additional changes needed in
embedding/browser/gtk and some makefile-fu to get those working properly.

Comment 21

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Looks like this slowed btek Tp by about 10ms.