You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is
highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If
there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.

Text widget -- the editor is used for text input and text
areas, both in XUL (e.g. the URL bar), and in HTML form
controls.

See the developer docs below
for more information about how the editor works.

The editor code lives in mozilla/editor/,
though we also rely on (and in some cases support) code in other areas,
particularly DOM range and selection (DOM
interfaces, range
and selection
implementation). We also maintain the output system: code to convert a
DOM document to some form of text (to plain
text, or HTML).

Editor code is currently packaged into 3 XPCOM component DLLs:

Library

DLL name*

Purpose

Win32

Unix

Mac

Editor

editor.dll

libeditor.so

EditorCore.shlb

Core editing functionality, interfaces with JS

Transaction Manager

txmgr.dll

libtxmgr.so

EditorTxmgr.shlb

Generic transaction handling (for undo/redo support)

Text Services

txtsvc.dll

libtxtsvc.so

TextServices.shlb

Provides simple interface to get text from a DOM document
(for Find and Spellcheck)

*note that names in debug builds may be different.

Editor user-interface files, consisting of XUL, JS, CSS and GIF
files for the editor window and dialogs live in mozilla/editor/ui/,
and, in a build, get installed to chrome/packages/core/editor/content/
and chrome/skins/<skin name>/editor/skin/.

Please feel free to comment on these documents in the editor
newsgroup/mailing list; see the community
page for details on how to subscribe.

Inevitably, as development progresses, some of these
documents will become out of date. Before embarking on any non-trivial
task based on information presented here, contact the editor group for the
latest details.

These spec documents describe the way we'd like the editor to behave
in response to various user-level actions, given the current editing
context and possible preference or other settings. They deal with
issues like "What happens if my selection point is in a paragraph, and
I type 'return'?"

HTML Typing Rules. The rules specifying
what happens when the user hits space, return, etc. in various
document contexts.

List Editing Rules. The rules
specifying what happens when the user uses the list toolbar
buttons or List Properties dialog

Selection. Selection is part
of layout, but the editor team is implementing it

As with the rest of the layout codebase, the current editor is based
on entirely new source, on top of the Gecko layout engine. There are no
parts of the old, 4.x-derived composer codebase that remain.

Information about the old
Composer is available; be warned that this code is no longer being
developed or maintained, but is still in the tree for those who might
want to reference it.

So you want to jump in and hack some code, tweak the UI, or write
docs or test plans? Excellent!

The first thing to do is to decide how you'd like to contribute.
We'd be very glad to have assistance in any of the following areas, so
let me list them, and say what kind of level of expertise would be
required for each one:

Major new features (e.g. publishing)
This would require significant work in C++ (probably creating a new XPCOMcomponent),
as well as UI work in XUL and
JavaScript.

Embedding the editor in another app
This is more a matter of XUL and JS coding, unless your hosting
application is written entirely in C++. See the embedding docs. You'll also
have to have a pretty good understanding of how the editor gets
instantiated and handles events (described here).

Improving the HTML typing rules; better HTML generation
The current HTML typing rules were written with HTML mail generation
very much in mind; they are not optimal for web page writing,
and we are aware of this. They are implemented in C++. You can
find out how to write new rule sets here. Note that a pretty good
knowledge of the DOM would be
required.

Helping fix memory leaks, performance problems, and bugs
We can always use help with memory usage, performance, and simply
more eyes on the code. This work would be almost entirely in
C++, and you'd probably want to use one of the commercially
available tools for your platform. Information on how to find
and fix memory leaks is here.
Other bugs, like crashes etc, require standard debugging
techniques, though tools like Purify
can sometimes help.

Tweaking the UI, adding minor new features
This you can do with a working knowledge of the XP Front-end (XPFE), which is a way
of describing UI appearance and behavior using an XML dialect,
XUL, and JavaScript. You can mess with the UI by playing with
the XUL, CSS and JS files in a downloaded binary. Look in chrome/packages/core/editor/content/
for editor-related XUL and JS, and in chrome/skins/<skin
name>/editor/skin/ for CSS and images. In the source
tree, these files are located in mozilla/editor/ui/

You should also be able to add new features by writing JS,
called from a menu item or context menu. To access editor
functionality, you'll need to call into the editor via the
editor shell. You can find out what it exposes to JavaScript by looking
at the IDL
file for the editorShell, nsIEditorShell.idl.

Helping with QA and testing
You can help here on a variety of levels, from just using the product
and filing bugs in Bugzilla when you can, to helping with test
plan and testcase development. You can find out more on the QA pages.