Burning Chrome

What a mess editorUtilities.js makes for us

I'm beginning to really hate the usage of the editor element in Mozilla Composer and Nvu. Because the way it's used in
both projects is a nightmare. Worse, it has worked for ages in this manner, so I may have a hard time convincing
anyone that its diapers need changing.

In Mozilla, the chrome://editor/content/editor.xul file has this excerpt:

    <deck id="ContentWindowDeck" selectedIndex="0" flex="1">

      

      <stack>

        <editor editortype="html" type="content-primary" id="content-frame"

                context="editorContentContext" flex="1" tooltip="aHTMLTooltip"/>

      </stack>

      <vbox>

        <label id="doctype-text" crop="right"/>

        <editor type="content" id="content-source" context="editorSourceContext" flex="1"/>

      </vbox>

    </deck>

Two editors. In case anyone hasn't noticed, Composer has four editing modes. 2 is not equal to 4, but through some very creative hacking (namely, adding in stylesheets through non-DOM C++ and doing some last-second JS to update the other editor element when it's needed), Composer makes it work. (Using one editor only would be ideal, but I can see some reasons why that wouldn't fly.)

This two-editor scheme causes problems for extensibility of Composer. A long time ago, someone filed bug 109682 to add DOM Inspector to Mozilla Composer. I wholeheartedly support that idea and plan on implementing it when I feel I can do so reliably.

Alas, transactions are broken between edit modes in Mozilla Composer. Just try this:
(1) Open an document in Mozilla Composer.
(2) Add a table in the Normal view.
(3) Switch to HTML Source view.
(4) In one of the cells, write something (Hi Mom).
(5) Switch to Normal View.
(6) Switch to HTML Source view.
(7) Check the Edit menu for the Undo command.

Expected results: Undo is enabled.
Actual results: Undo is disabled.

To the user, this is inexplicable. The user thinks he's editing one document when he's really editing three. The first is the baseline document under the Normal view. The second is the document he creates when he switches to Source view the first time. When he switches back to Normal view, all his transactions in Source view become one transaction for the normal editor element -- and surprise, the transactions in the Source view get wiped out. So when he goes back to editing in Source view, it's like starting with a whole new document.

Unfortunately, this particular bug is a WONTFIX per comments in editor.js:

  else if (previousMode == kDisplayModeSource)

  {

    // Only rebuild document if a change was made in source window

    if (IsHTMLSourceChanged())

    {

      // Reduce the undo count so we don't use too much memory

      //   during multiple uses of source window 

      //   (reinserting entire doc caches all nodes)

      try {

        editor.transactionManager.maxTransactionCount = 1;

      } catch (e) {

Now, I can see that being practical when the user puts out bad HTML markup for the Normal view. (What can we do about that?) But even so, a 1-to-1 correspondence based on caret positioning would be MUCH smoother.

To implement DOM Inspector safely, I would first have to force the primary editor to get its update if I'm leaving the HTML source mode. Even so, this doesn't really fix the undo/redo scheme.

Nvu is even worse in regards to switching edit modes. It uses a tabeditor to let you edit multiple documents. But thanks to the way it's used as of Nvu 0.2 (namely, to replace the first editor of two in editor.xul and not both of them), when you switch to HTML Source editing mode, you lose the ability to switch documents! This is understandable considering it's 0.2, but even so, it's sloppy. The underlying bug, using two editor elements in the first place, forced this implementation. I'd call the loss of tab editing in Source view a major bug.

Posted by WeirdAl at June 6, 2004 3:43 PM