369571 - Make nsEditingSession extensible (makeWindowEditable) via JS components?

Status: NEW

(Core :: DOM: Editor, enhancement, P5)

Description

[Alex Vincent [:WeirdAl]]

I'm looking at nsEditingSession, and thinking I'd really love to have my own editor (like a JS-based nsIEditor component, for XML editing).  Unfortunately, it has a hard-coded component class ("@mozilla.org/editor/htmleditor;1") and four hard-coded types (from nsIEditingSession, "html" "htmlsimple" "text" "textsimple").  These cannot currently be extended by any additional components.

What I'd like to do is define a category for additional editor components, which themselves work with a particular editor type.  When an unrecognized type shows up, the editing session code should search this category for acceptable types.

Any thoughts?

Comment 1

[Kathleen :Brade]

I know we talked about supporting other types for editing but that was years ago and I can't remember the specifics right now.  I think part of the discussion had to do with what gecko can render, another part of the discussion had to do with some of the underlying assumptions for the editor (e.g. it'd be hard to write an image editor since we rely heavily on DOM).  Maybe someone else remembers more...

Comment 2

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

yes, yes and yes. Excellent idea, we at Disruptive Innovations would use it
for Composer (Nvu++) and Etna, our XML editor.

Comment 3

[Alex Vincent [:WeirdAl]]

Okay, so here's my thought on a test case:  a JavaScript component which wraps around the original HTML editor.  Every call to a method of the JS component passes through to the HTML editor, but with a nice dump() statement included so you know it worked.  Also a dump() statement in the constructor, to let us know the component was initialized by the editing session.  Nice, neat, simple; we'd not have to really implement any new editor functionality in order to test.

Comment 4

[Alex Vincent [:WeirdAl]]

nsIEditor.idl has one non-scriptable method, init(), which always gets called:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/editor/idl/nsIEditor.idl&rev=1.32&mark=97#97

So we need a little redirection.  We need a C++-based editor wrapper to take init's aEditorType argument and get the real JS editor wrapper.  Probably also a nsIScriptableEditor.init() method as well to pass in values that go before nsIEditor.init().

Alternatively, we would need a scriptable initialization method on nsIEditor.  The init() method itself is probably specific to the HTML editor (and why it comes after so many other nsIEditor() calls is a mystery to me).

Comment 5

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.