43121 - pull XUL content model out of rdf.dll

Status: RESOLVED FIXED

(Core :: XUL, defect, P3)

Description

[Chris Waterson]

An issue that has been coming up more frequently with respect to
embedding has been proper factoring of our DLLs. A couple of us were
talking today and came up with some ideas to better factor one of our
largest offenders, librdf.so.


Summary

I'd like to take the contents of rdf/content/src and move them to
layout/xul/content/src, layout/xul/content/document, and dom.

I'll be breaking things along the same lines that HTML and XML content
do (./document gets content sink and document files; ./content gets
content node files; ./dom gets vidur-IDL and stubs).

Some of the files that move to DOM will live there only until hyatt and
ben can get rid of the JS glue, replacing it with its XBL equivalents;
others will become permanent residents (nsJSXULElement.cpp and
nsJSXULDocument.cpp, for example). These could theoretically be
controlled by "#ifdef INCLUDE_XUL".

The files that move to layout/xul will be built into a standalone DLL,
libxul.so, which will have no link-time dependencies on anything else in
the layout directory.


Background

librdf.so is a 1Mb DLL (optimized, Linux) that holds both the XUL
content model (about 80% of its bulk) and some miscellany used to parse
RDF/XML and maintain in-memory datasources.

libchrome.so is a 150Kb DLL that uses librdf.so to properly indirect
"chrome:" URLs.

Necko, Gecko, and others are pull libchrome.so and librdf.so into their
dependency graph primarily because of reliance on "chrome:" URLs (e.g.,
to load string bundles, to provide skin-switching capabilites for XUL). 

  - The "chrome registry" is an RDF/XML file which stores the
    indirection information

  - The chrome registry is used to provide propery indirection
    to the currently selected locale.

To date, no embedders require this functionality.

Strictly speaking, XUL can run *without* RDF and the chrome registry
with only modifications to the XBL and CSS files it uses. (Replacing
"chrome:" URLs with "resource:" URLs, for example.)

The XPFE team is currently working to break link-time dependencies on
nsContainerFrame, and eventually plan to be able to 


Rationale

Going forward, we need to make a decision with respect to embedding. To
include XUL, or not to include XUL?

XUL makes many embedding issues extremely straightforward: it provides
dialogs, tooltips, context menus, focus management, command updating,
and someday may even provide the widget set itself via XBL.

This flexibility currently comes with a fairly large footprint cost: on
Linux, the XUL content frames account for 15% of libraptorhtml.so's size
(about 1Mb out of 7Mb), and 80% of librdf.so's size (800Kb out of 1Mb).

While it may make sense in the long run to re-use XUL and XBL within
HTML, in the short term, having a plan to factor XUL into its own module
seems to make the most sense.

This separates RDF/XML and chrome resolution from core XUL content,
reducing XUL content's payload by about 30%; RDF/XML and chrome would
live in their own 200Kb and 150Kb libraries, saving a 350Kb code
footprint.


Future

If nsCSSFrameConstructor could dispatch on namespace, and with
additional effort to remove the XUL frames' depenency on
nsContainerFrame, XUL frames could theoretically live in their own DLL.
This would reduce the core HTML layout engine's size by about 15%.

In theory, this would allow Gecko to be embedded without XUL; however,
it would require us (well, jud and rpotts) to design solutions for at
least the following problems:

  1. maintaining focus state
  2. handling keybindings (e.g., PgUp PgDn)
  3. event propogation to the HTML container
  4. tooltips, context menus, dialogs, ...

(Hyatt can discuss these better; I'm sketching...)

Alternatively, XUL and XBL could form the basis for the existing form
controls. Right now, the bulk (about 36%) of libraptorhtml.so comes from
the HTML content elements, many of which are form controls. Using XBL,
many of these could be replaced with JS implementations which have
negligible footprint.

In any case, factoring out XUL's content elements and co-locating in the
source tree them with the XUL frames seems to make sense, even if the
content nodes continue to live in their own DLL.

Comment 1

[Chris Waterson]

dougt said he'd belly up to the task because this is important for embedding.
Here are the things that need to happen:

1. Move DOM-IDL files in rdf/content/public/idl to dom/public/idl/xul, generate
headers into dom/public/xul, generate source into dom/src/xul, link with
JDDOM.DLL (possibly #ifdef INCLUDE_XUL, if you can).

2. Move remaining files from rdf/content/[src|public] to
layout/xul/content/[src|public]. These files should be linked into a separate
XUL.DLL, *not* GKHTML.DLL. (hyatt: please expand if there are files that are
exceptions to this rule and should be made part of the main layout build, e.g.,
nsControllerCommandManager.cpp, aka nsAnalMicroManagingBeuraucrat.cpp)

3. There are a couple of XPIDL interfaces in rdf/base/idl that should be moved
into layout (xulstudbs.idl, nsIXULSortService.idl, nsIXULTemplateBuilder.idl,
nsIController.idl, nsIControllers.idl, and that saucy dominatrix
nsIControllerCommand.idl).

4. Get leaf to help you copy the ,v files so that we can keep CVS history!

hyatt: is there anything I forgot?

Comment 2

[Doug Turner (:dougt)]

never got around to this.  Per a conversation with hyatt a few weeks ago, I am
reassigning to him. 

Comment 3

[Peter Trudelle]

->waterson cuz hyatt sez yer already workin on it

Comment 4

[Chris Waterson]

I have this working on Windows now. Here is a summary of what I've done.

- Moved the following files:

* XUL DOM glue now lives in the JS-DOM DLL.
  rdf/content/public/idl/XULCommandDispatcher.idl
                         XULDocument.idl
                         XULElement.idl
                         XULTreeElement.idl
     --> dom/public/idl/xul

  rdf/content/public/nsIDOM*.h
     --> dom/public/xul

  rdf/content/src/nsJSDOM*.cpp
     --> dom/src/xul

* Created a `layout/xul/document' directory.
  rdf/content/idl/nsIController.idl
                  nsIControllers.idl
                  nsIControllersCommand.idl

  rdf/content/public/nsIXULContentSink.h
                     nsIXULDocument.h
                     nsIXULPrototypeCache.h
                     nsIXULPrototypeDocument.h
     --> layout/xul/document/public

  rdf/conteont/src/nsElementMap.cpp
                   nsElementMap.h
                   nsForwardReference.h
                   nsXULCommandDispatcher.cpp
                   nsXULCommandDispatcher.h
                   nsXULContentSink.cpp
                   nsXULControllers.cpp
                   nsXULControllers.h
                   nsXULDocument.cpp
                   nsXULDocument.h
                   nsXULPrototypeCache.cpp
                   nsXULPrototypeDocument.cpp
     --> layout/xul/document/src

* Added to the `layout/xul/content' directory

   rdf/content/public/nsIXULContent.h
                      nsIXULPopupListener.h
     --> layout/xul/content/public

   rdf/content/src/nsIRDFNodeList.h
                   nsIXULTreeContent.h
                   nsRDFDOMNodeList.cpp
                   nsRDFDOMNodeList.h
                   nsXULAtoms.cpp
                   nsXULAtoms.h
                   nsXULAtoms.inc
                   nsXULAttributeValue.cpp
                   nsXULAttributeValue.h
                   nsXULAttributes.cpp
                   nsXULAttributes.h
                   nsXULElement.cpp
                   nsXULElement.h
                   nsXULPopupListener.cpp
                   nsXULTreeElement.cpp
                   nsXULTreeElement.h
     --> layout/xul/content/src

* Created a `layout/xul/templates' directory.
  rdf/content/idl/nsIXULSortService.idl
                  nsIXULTemplateBuilder.idl

  rdf/content/src/nsIRDFContentModelBuilder.h
     --> layout/xul/templates/public

  rdf/content/src/nsRDFSort.h
                  nsRuleNetwork.cpp
                  nsRuleNetwork.h
                  nsXULContentUtils.cpp
                  nsXULContentUtils.h
                  nsXULSortService.cpp
                  nsXULTemplateBuilder.cpp
     --> layout/xul/templates/src

- Re-ordered RDF to earlier in the build (well before layout). RDF no
  longer needs to depend on JS, GFX, or DOM, but layout needs to be
  built after RDF because XUL has some IDL that talks about RDF
  interfaces (the template builder stuff, which for now is going in
  the layout DLL because it's pretty tightly tied up with the content
  model stuff.)

- Turned off building `rdf/tests/domds': it needs to find a better
  place to live than in the RDF directory.

- Renamed contract-IDs from `@mozilla/rdf/xul-*' to
  `@mozilla/xul/xul-*' (e.g., `@mozilla/rdf/xul-prototype-cache;1'
  became `@mozilla/xul/xul-prototype-cache;1').

- Got rid of `nsIXULContentUtils' interface. This was only being used
  outside the `layout/xul' directory to determine if XUL prototype
  caching was `on' (e.g., nsCSSLoader, nsXBLService). I just added a
  method to the prototype cache that allows you to ask if it's on or
  not.

- Consolidated some of the common content sink routines into
  `layout/base/src/nsParserUtils.[h|cpp]', and fixed the XML and HTML
  content sinks to use these. (The XUL content sink was previously
  using `nsRDFParserUtils', so I needed to find a replacement for
  those utility routines.)

Comment 5

[Chris Waterson]

Slipping to 0.9; gated on heikki's work for 43142. Also, I don't know why this 
bug depends on 39965: it doesn't.

Comment 6

[Chris Waterson]

Attachment: gzip'd diffs

Comment 7

[Chris Waterson]

A million apologies for attaching gzip'd diffs, but the uncompressed version was
too big for bugzilla. Looking for some r= and sr= love here; hoping to land this
tomorrow after dougt's stuff winds up...

Comment 8

[David Hyatt]

rs/sr=hyatt

Comment 9

[Johnny Stenback (:jst)]

r=jst

Comment 10

[Brendan Eich [:brendan]]

rs=[e-mail]

Our widdle baby's all growds up!

/be

Comment 11

[Chris Waterson]

Attachment: couple more changes: contract ID cleanup, get correct XPT names

Comment 12

[Chris Waterson]

Done, sorta sloppy. Need to take a second pass through to make #ifdef's work 
right and stuff...