The Mozilla editor provides HTML and plain text editing functionality in Gecko-based applications. Internally, the editor code manipulates page content primarily using DOM calls, so it is a true DOM-savvy editor. It also supports IME (international text input), and is mostly accessible from JavaScript.
The editor is currently used in three different ways in the Mozilla codebase, though each application shares the same underlying code:
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/.
Please feel free to comment on these documents in the editor newsgroup/mailing list; see the community page for details on how to subscribe.
Note: 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.
Brian King has also written some documents about extending the editor, at the O'Reilly DevCenter.
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'?"
These specs deal with parts of the UI such as the main window, dialogs, menus, context menus etc.
Some specs concerning lower-level details of specific areas in the editor.
Test plans and testcase used by QA (Quality Assurance) to determine whether features work (i.e. to look for bugs).
The following documents are intended mainly for a developer audience, and get down to the nitty-gritty about how the editor works.
Some more generic "how-to" documents
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 XPCOM component),
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/ 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.
An outline of some composer test cases is available.
(remove any spaces and replace AT with @ and dot with .)
If you want to know who to contact for a particular problem or code area, this table is your best resource.
The newsgroup for discussing Mozilla editor issues is netscape.public.mozilla.editor, and members of the editor team regularly read and post to that newsgroup. It is gatewayed into the mailing list mozilla-editor; subscribe here (put "subscribe" as the subject of the message).