- What is the editor?
- Editor documentation
- Developer information
- Historical information
- Who are we?
- How can I help?
- How to reach us
The editor is currently used in three different ways in the Mozilla codebase, though each application shares the same underlying code:
- Composer -- a fully-fledged HTML editor, for writing web pages.
- Embeddable HTML editing widet -- a rich text editing tool, used in mail compose, instant messaging and other areas.
- 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
though we also rely on (and in some cases support) code in other areas,
particularly DOM range and selection (DOM
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:
||Core editing functionality, interfaces with JS|
||Generic transaction handling (for undo/redo support)|
||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
and, in a build, get installed to
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
- Adding basic CSS 1 Support to the Editor describes a proposal for the addition of CSS 1 support to the Editor.
These specs deal with parts of the UI such as the main window, dialogs, menus, context menus etc.
- Main composer window specs. Not available yet.
- Mail compose specs. Not available yet.
- Menu specs. Not available yet.
- Context menu specs. Not available yet.
- Dialog Specs. Specs for the various composer dialogs (somewhat outdated).
- Table Editing Specs. Specs for table editing (somewhat outdated).
Some specs concerning lower-level details of specific areas in the editor.
- Key Event Specification Not just for the editor, but for the whole Mozilla app.
- Transaction/Undo Manager A general-purpose set of classes, usable by clients outside the editor too
- Selection spec Selection is part of layout, but the editor team is implementing it
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.
- How the editor works -- editor instantiation and event handling
- Embedding the editor in another application
- Embedding a plaintext-only editor
- Editor as the text widget
- Command execution and enabling in the UI
- The Transaction Manager, which allows for undo/redo.
- The Text Services, a way for clients to access the text of a DOM document easily, without having to know about the details of the document format.
Some more generic "how-to" documents
- Care and Feeding of the Find Algorithm
- Notes on the DOM serializers (how html and plaintext output is created)
- How to modify an idl file in the DOM IDL world
- Writing Property Dialogs for 5.0 that use the Advanced Edit feature
- Editor API Logging -- Allows users to record edits made to a document and play them back.
- Composer runtime table -- list of required libraries and files, with their sizes (somewhat out of date)
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:
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
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
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 .)
- Kathy Brade (brade at comcast dot net)
- Joaquin Blas (kin at netscape dot com)
- Ryan Cassin ("Hurricane") (rcassin at supernova dot org)
- Joe Francis (jfrancis at floppymoose?)
- Daniel Glazman (daniel at glazman dot org)
- Neil Rashbrook (neil at parkwaycc dot co dot uk)
- Charles Manske (cmanske at jivamedia dot com)
- Akkana Peck (akkana at netscape dot com)
- Simon Fraser (sfraser at netscape dot com)
- Beth Epperson (beppe at netscape dot com)
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).
Last modified Tursday 15 February 2001
Maintained by the editor team: email@example.com