302099 - How do embedders embed libxul?

Status: RESOLVED FIXED

(Toolkit :: Startup and Profile System, defect, P2)

Description

[Benjamin Smedberg]

Supposedly libxul is supposed to be the next-generation embedding framework, but
currently embedders cannot "get at" the gecko components, because they are
statically linked. There are a couple options here, and I intend to implement
both of them:

1) expose the gecko static component list through a frozen API
XRE_GetStaticComponents. Embedders could get the static component list and then
call NS_InitXPCOM3 with this list (adding additional components as appropriate).

2) expose and freeze NS_InitEmbedding and the event-processing symbols directly
from libxul, instead of making them a static library... NS_InitEmbedding would
automatically get the gecko static components and initialize XPCOM with them.

I'm also going to try and get mfcembed/gtkembed/activex control to build using
libxul, to test that embedding actually works in this context. The amount of
testing we (don't) get for embedding contexts is depressing.

Comment 1

[Benjamin Smedberg]

Attachment: Part 1 - expose XRE_GetStaticComponents [checked in on 1.8 branch]

Comment 2

[Darin Fisher]

Comment on attachment 193825 [details] [diff] [review]
Part 1 - expose XRE_GetStaticComponents [checked in on 1.8 branch]

r=darin

By the way, it looks like xpcom/components/nsStaticComponent.h should be CVS
removed.

Comment 3

[Benjamin Smedberg]

Comment on attachment 193825 [details] [diff] [review]
Part 1 - expose XRE_GetStaticComponents [checked in on 1.8 branch]

This is basically no-risk for the aviary apps (or anyone else for that matter).

Comment 4

[Benjamin Smedberg]

Attachment: XRE_InitEmbedding, rev. 1

This builds, but I don't really have a way to test it in this tree. If it looks
good, I'd like to land it (on trunk) and then continue testing it on various
platforms and in various embedding contexts.

Comment 5

[Darin Fisher]

Comment on attachment 194471 [details] [diff] [review]
XRE_InitEmbedding, rev. 1

>Index: toolkit/xre/nsEmbedFunctions.cpp

>+  nsEmbeddingDirProvider(nsILocalFile* aGREDir,
>+			 nsILocalFile* aAppDir,
>+			 nsIDirectoryServiceProvider* aAppProvider) :

nit: replace tabs with spaces (problem occurs elsewhere too)


>+  sCombined = (nsStaticModuleInfo*)
>+    malloc(sizeof(nsStaticModuleInfo) * combinedCount);

nit: operator new[] perhaps?


>+  nsStaticModuleInfo *current = sCombined;
>+  PRUint32 i;
>+  for (i = 0; i < kStaticModuleCount; ++i) {
>+    *current = kPStaticModules[i];
>+    ++current;
>+  }
>+
>+  for (i = 0; i < aStaticComponentCount; ++i) {
>+    *current = aStaticComponents[i];
>+    ++current;
>+  }

these look like two calls to memcpy to me :)


so, it looks to me like an embedder will still need to manage their
own profile directory.	we don't yet give them a canned directory
service provider that does that for them, right?


r=darin

Comment 6

[Benjamin Smedberg]

> so, it looks to me like an embedder will still need to manage their
> own profile directory.	we don't yet give them a canned directory
> service provider that does that for them, right?

For the moment, yes. We need to think about this a lot more carefully in 1.9,
especially WRT profile sharing and having the embed apps run basically
"profileless". For right now, they should statically link the
profdirserviceprovider_s thingie and use it (it is glue-safe under the right
circumstances).

Fixed on trunk. I'll use new bugs to patch the various embedders to actually use
this API for testing purposes before requesting 1.8 branch approval.

Comment 7

[Asa Dotzler [:asa]]

time is short for beta so if this is gonna make the branch, it needs to land ASAP.

Comment 8

[Asa Dotzler [:asa]]

 If this isn't landed today, it's not going to make the train.

Comment 9

[Benjamin Smedberg]

This is not going to make b4, and doesn't need to. We can get it done later as
necessary.

Comment 10

[Benjamin Smedberg]

Comment on attachment 193825 [details] [diff] [review]
Part 1 - expose XRE_GetStaticComponents [checked in on 1.8 branch]

Part 1 checked in on the 1.8 branch.

Comment 11

[Asa Dotzler [:asa]]

what's left here and is part >1 a blocker to 1.5?

Comment 12

[Benjamin Smedberg]

Per discussion with darin, part 2 does not need to land on 1.8 branch.

Comment 13

[jhp (no longer active)]

Comment on attachment 194471 [details] [diff] [review]
XRE_InitEmbedding, rev. 1

Requesting 1.8.0.1 approval.  This patch is XULRunner only and doesn't affect Firefox or Thunderbird.  This code is needed by the Javaconnect code, to allow embedding XULRunner in Java.

Comment 14

[Mike Schroepfer]

Comment on attachment 194471 [details] [diff] [review]
XRE_InitEmbedding, rev. 1

Please consider for 1.8.1 - 1.8.0.1 is for major security and crash issues only.

Comment 15

[Benjamin Smedberg]

Comment on attachment 194471 [details] [diff] [review]
XRE_InitEmbedding, rev. 1

Re-requesting approval per drivers email, this is not built into anything except libxul/xulrunner.

Comment 16

[Benjamin Smedberg]

Comment on attachment 194471 [details] [diff] [review]
XRE_InitEmbedding, rev. 1

a=drivers

Comment 17

[Benjamin Smedberg]

XRE_InitEmbedding bits landed on 1.8.0.1 and 1.8.1