mfinkle found out that <browser> doesn't have these problems, so a temporary workaround is to user browser instead of editor. Then in order to get <editor> stuff:
var myBrowser = document.getElementById('myBrowser');
var editingSession = myBrowser.webNavigation.QueryInterface(Components.interfaces.nsIInterfaceRequestor).getInterface(Components.interfaces.nsIEditingSession);
myBrowser.contentDocument.designMode = 'on';
var editor = editingSession.getEditorForWindow(myBrowser.contentWindow);
var commandManager = myBrowser.webNavigation.QueryInterface(Components.interfaces.nsIInterfaceRequestor).getInterface(Components.interfaces.nsICommandManager);
var htmlEditor = editor.QueryInterface(Components.interfaces.nsIHTMLEditor);
Works for now, until this bug is fixed.

It has property commandManager, and methods getHTMLEditor and getEditor for instance.
But the critical point is that the editor element simply doesn't work for what it is designed for, to edit stuff. So all extensions and such using a <editor> will not work, and break stuff when it comes down to executing commands like bold, italic, link, etc. I can't see how that can not be critical?

Using commandManager like that works here too. But not contentDocument.execCommand (and similar calls) as it did before 2004-04-18.
Quote from http://developer.mozilla.org/en/docs/XUL:editor
<blockquote>
Once editable, the document can have special formatting and other HTML pieces added to it using the document.execCommand method:
var editor = document.getElementById("myEditor");
// toggle bold for the current selection
editor.contentDocument.execCommand("bold", false, null);
</blockquote>
I suppse it's not only my code that will suffer from this bug.

Created attachment 546023[details][diff][review]
Patch (v1)
For <xul:editor>, the HTML document's mEditingState ended up being eOff, which effectively disables the execCommand API. This patch is a simple fix for that.