Re: Summary of the situation with the composition process — thoughts wanted

Ehsan Akhgari ehsan.akhgari at
Tue Jun 21 21:36:41 UTC 2011

On Tue, Jun 21, 2011 at 2:35 PM, Jonathan Protzenko
<jonathan.protzenko at> wrote:
> The <editor> component from Gecko; it handles the editable area, i.e. where
> you type your message, the caret, what happens when you hit enter, the DOM
> tree, etc. The code lives in comm-central/mozilla/editor/. :ehsan and :kaze
> are working on it if I'm not mistaken.

Just to correct a bunch of facts, kaze has not started yet, and the
caret code lives outside of the editor (as we support carets even for
non-editable areas).

> The editor UI: all the small buttons to insert an image, set text in bold,
> italics, etc. The code lives in comm-central/editor/ui. It's horrible code,
> that hasn't changed for the past 10 years, and unlike wine, it doesn't get
> any better with age. AFAIK, no one's working on it, and we definitely need
> help with it. The number of steps required to merely insert an image is
> complete nonsense, and the process is not intuitive.

FWIW, I have not looked at that code, and it's not on my list (mainly
because it's not used in Firefox).

> Given that we don't have that many resources to devote to the composition UI
> (2.), this would allow us to cheaply get an updated, more intuitive UI.

ckeditor is way more than just the UI for the editor.

> Make the composition code more accessible to developers. Hacking into that
> C++ code is insanely hard, the entry cost is high, and it's scary. Writing
> it in JS would make it more concise, lighter, and more hackable. We could
> also drop large chunks of code that make no sense today : the C++ code goes
> great lengths to figure out the best encoding to sent the outgoing message
> with. In compose in a tab, I settled for UTF8 always, and saved myself a lot
> of trouble.

Is that a good choice?  For example, are there mail clients which are
not capable of correctly handling UTF-8?  (It's not a rhetorical
question, I don't really know).

> I rewrote this part in JS, and I've implemented most required actions. This
> is either code that determines the recipients depending on the composition
> mode, streams the draft to insert its body into the edition area, re-uses
> the attachments from the draft, or the forwarded message, etc; or code that
> performs less pleasant tasks, such as rewrapping the text, quoting and
> rewrapping, or convert html to plaintext (do you realize that the component
> in Thunderbird that does html -> plaintext conversion for quoting is not
> even scriptable?).
> This part heavily relies on an <editor> being available, so I had to fake
> myself into a nsIEditor and a nsIEditorMailSupport. This roughly works, but
> I had to resort to the most vicious hacks to get this done (more details in
> an appendix).

So, this would mean that we have to maintain two versions of the same
code in the future (one in ckeditor, the other in editor/)?  Or are
you also going to change the SeaMonkey usages of this code?

Also, nsIEditor is not going to remain in its current shape for a long
time, so I wouldn't design any APIs on top of it if I were you.  :-)

> There are many problems, though.
> CKEditor tries to be cross-platform

Correction: cross-browser.

> and hence overrides many builtin
> <editor> features, making them slower and more error-prone. For instance,
> CKEditor will have its own handling of the <Enter> key, and will break the
> DOM tree on its own, move the caret... CKEditor has its own spellchecking
> also. CKEditor is very much heavyweight, takes seconds to load, and doesn't
> necessarily fit well as the UI for a mail editor (issues with
> <blockquote>s).

What are the upsides of taking ckeditor's code, besides getting a new
shiny and sexy editor UI really fast?  What are the maintenance costs?
 Do they have tests?  Do you have plans to address these downsides?
(Note that some of them, such as ckeditor trying to implement its own
editing features are pretty intrinsic parts of that project.)

> The Herculean undertaking that this represents. There are zillions of
> options and of possible behaviors; more than a sane man would get crazy
> trying to implement them all. I even regularly discover some new options
> myself: the thing with multiple identities for one single account, all
> preferences regarding composition (top-posting vs bottom-posting, signatures
> above/below the quote, signature / no signature, quote / no quote, font,
> color, html, plaintext, html + plaintext, utf8, no utf8), s/mime, attachment
> reminder, MDN, DSN, autosave, different composition modes (edit draft,
> reply, reply all, new, etc. I think there are 14 of them), initial
> attachments, were we called through mapi, command-line, drag&drop of
> attachments from: the filesystem, another email, an URL... I believe some of
> these options should go away, even if some users are going to crucify us for
> this. I don't think we have the manpower to undertake a rewrite of the
> composition process and still afford to keep that variety of customizations.
> There are hidden invariants all over the place. Specific design patterns
> that oblige you to re-use a specific object, and modify it in place. Very
> specific calling conventions. Hidden state that require you to call just the
> magic function so that it will fail after 10 lines because you're not
> implementing the right interfaces, but will still set the global variable to
> the right value. More generally, the expectation that the only place we will
> ever compose messages from is the composition window.

I'm in general all in favor of simplifying things.  But reading this
message, I got the feeling that we're attacking this problem
backwards.  Implementation constraints should not really dictate the
features of a product.  I think we should try to determine which ones
of those features we want to keep and which ones we want to throw
away, and then model our implementation around those decisions.


More information about the tb-planning mailing list