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.

Skip to main content

Mozilla Editor

What is the editor?

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:

  1. Composer -- a fully-fledged HTML editor, for writing web pages.
  2. Embeddable HTML editing widet -- a rich text editing tool, used in mail compose, instant messaging and other areas.
  3. 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/.

Editor documentation

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.

Brian King has also written some documents about extending the editor, at the O'Reilly DevCenter.

Behavior specs

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.

UI specs

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).

Implementation specs

Some specs concerning lower-level details of specific areas in the editor.

Test plans

Test plans and testcase used by QA (Quality Assurance) to determine whether features work (i.e. to look for bugs).

Developer information

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

Historical information

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.

How can I help?

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/<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.

    An outline of some composer test cases is available.

Who are we?

(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.

How to reach us

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: mozilla-editor@mozilla.org