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

JoeS joesab2005 at gmail.com
Tue Jun 21 22:24:43 UTC 2011


On 6/21/2011 2:35 PM, Jonathan Protzenko wrote:
> The compose window in Thunderbird relies on three broadly defined 
> components.
>
>  1. 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.
>
>     Ehsan and Kaze are working on it , but not from the POV of a mail
>     editor.Although I think that almost anything that can be done in a
>     web page should be possible in an email. That assumes that CSS is
>     allowed in emaill...an assuption that has been vehemently opposed
>     in the past. If you look at the horrible code produced by the MS
>     word html editor (and deemed to be acceptable media) surely we
>     should loosen our "stance" on including/encouraging good HTML/CSS.
>
>  2. 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*.
>
>     If you think inserting an image is not intuitive, try using the
>     /Advanced Editor /to add some inline styles. Oh, to get into that
>     editor, you just double click on the image and choose "advanced"
>     You can add inline styles, but you must know the exact correct
>     syntax. There is no help there at all, and properties are removed
>     if you attempt to edit pre-composed code.
>
>  3. The code for setting up a compose session and sending the message.
>     It's all c++, and I'm thinking about
>     comm-central/mailnews/compose/src/, most specifically
>     nsMsgCompose.cpp and nsMsgSend.cpp.
>       * The code first initializes the composition window, does a lot
>         of magic, sets up all the composition fields, both visible and
>         hidden (recipients, subject, headers, quoted & reformatted
>         text, signature, MDN, etc.). It talks to the nsIEditor that
>         the <editor> implements to setup html / plaintext editing, the
>         encoding, etc.
>       * Then, nsMsgSend.cpp kicks in, walks the DOM tree, figures out
>         which images should be attached, determines whether html +
>         plaintext or just plaintext should be sent, changes the src
>         attributes live in the <editor> instance so that <img
>         src="blah.jpg"> becomes <img src="cid:whatever"> and then
>         serializes it all according to the right encoding, wraps it,
>         sends it.
>
>         Yes, the CID whatever is problematic from a couple of
>         different aspects. CSS background-image comes to mind. I think
>         the problem there is Libmime. A few yaers back, one of the
>         veteran core devs started to look at that, but withdrew
>         because that code /"Made his eyes bleed" ;-) /
>

Thanks for bringing this subject up. But please remember that folks have 
been fighting these editor quirks for years  and coming up with their 
own little work-arounds. Any feature that you prune out, might just be 
that needed feature.


-- 
JoeS



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20110621/a660423d/attachment.html>


More information about the tb-planning mailing list