221600 - GRE: remove the references to files packaged in comm.jar

Status: RESOLVED WORKSFORME

(Core Graveyard :: Embedding: GRE Core, defect)

Description

[Pierre Chanial]

A grep on "chrome://communicator" in dist/gre gives:
./components/libprofile.so
./components/libnecko.so
./components/libcaps.so
./components/libhtmlpars.so
./components/libgklayout.so
./components/libembedcomponents.so
./components/libnsappshell.so
./components/libxpinstall.so
./components/libwallet.so
./libgkgfx.so

Grepping "chrome://navigator/" gives:
./components/libnsappshell.so
./components/libtypeaheadfind.so

GRE should depend on toolkit.jar (the new and the old one) but not on the fat
comm.jar.

Comment 1

[Benjamin Smedberg]

Some/many of these references should not be chrome:// at all: see bug 215212,
they should be using a locale-service that I have yet to complete.

The "core gecko/HTML" parts of GRE should not even depend on toolkit.jar... we
should make embed.jar a real file instead of the hacked-together embedding-only
JAR. We should ship it with the GRE (see bug 180429).

Comment 2

[Pierre Chanial]

I may agree that the core html gecko part of the GRE should not depend on
toolkit.jar, but because of the fact that the GRE will always be able to render
XUL (correct me if I am wrong), I am not sure that the distinction between core
GRE and whole GRE is pertinent.
I've not heard of a GRE with XUL disabled and if I understand correctly, it
would not be easy to have a XUL run-time on top of a XUL-disabled GRE.

In fact, I don't see the point of splitting toolkit.jar in two: a part that
would go in the GRE and another that wouldn't. The frontier between both is,
imho not so clear.
Let's take an example: the profile manager or the print setup page on which the
GRE depends on. If we include it in the GRE, then, following the dependency
rule, all the XUL widgets and css files (defined atm in toolkit.jar) should be
included in the GRE. But then, there would not be much left in toolkit.jar.

In the future, I would rather be in favor of including toolkit.jar to the GRE
and perhups having an embed.jar files that would contain the strict minimum to
create an app that doesn't need xul if it justified for perf reasons: since the
GRE will always be able to render XUL, then toolkit.jar can be shipped for free
even if the majority of it would not be used by the embedors that don't need XUL.

Comment 3

[Benjamin Smedberg]

I don't know precisely what your goal is with this bug... obviously gecko should
not depend on chrome://communicator URIs, but before patching, we need to decide
exactly what it *should* depend on, and where that will be delivered.

I just want to make sure that you're not at cross-purposes with this goal: make
the GRE a self-contained embeddable solution for HTML-only embedders (for
example, mfcembed). toolkit.jar is forked between seamonkey, firebird, and
thunderbird, and will remain so forever, pretty much; I don't see how you could
ever ship it with the GRE. Of course the XUL layout parts of gecko are going to
depend on one of the toolkits, but for the most part that is not where the big
problem lies.

Comment 4

[Pierre Chanial]

> I don't know precisely what your goal is with this bug... obviously gecko 
> should not depend on chrome://communicator URIs, but before patching, 
> e need to decide exactly what it *should* depend on, and where 
> that will be delivered.
The purpose of this bug is to not ship comm.jar with Phoenix.
I think that as a cheap first step, we should package the comm.jar files in
toolkit.jar. Then, if necessary, we could split toolkit.jar into 2 parts (->
embed.jar).

> I just want to make sure that you're not at cross-purposes with this goal: 
> make the GRE a self-contained embeddable solution for HTML-only embedders 
> (for example, mfcembed). toolkit.jar is forked between seamonkey, firebird, 
> and thunderbird, and will remain so forever, pretty much; I don't see how 
> you could ever ship it with the GRE. 
Well, shipping toolkit.jar with the GRE is not my top priority. I agree that
there are differences between the toolkit used by firebird and seamonkey, 
but they are compatible wrt the GRE and seamonkey could easily use the new
toolkit. Concerning Thunderbird, the transition to the new toolkit is not
finished. XRE is only GRE+toolkit.jar, so at the end, a toolkit will prevail and
will be chosen.

If we agree to put the current comm.jar dependencies in toolkit.jar: then please
head on bug 221603 and bug 194678.

Comment 5

[Benjamin Smedberg]

This happened, gradually.