Need to implement embedding APIs for editor.

Sorry for the spam, changing QA contact.

Grab

setting to m18 for now

nom. doug should you get this?

Here's what needs to happen, I think, to make editor more embeddable in XUL applications. The editor functionality is exposed through various non-xpidl interfaces in mozilla/editor/public (e.g. nsIEditor, nsIHTMLEditor etc). Interaction with JavaScript happens via nsIEditorShell, which acts as a fairly thin shell around the editor, and is exposed via xpidl. (The editor shell is really just a heavily mutated appcore from the old days.) It is the responsibility of the editor shell to observe URL loads on the iframe that is editable, and to instantiate the editor when the OnEndDocumentLoad notification is received. The editor shell can be created in two ways. The 'old' way is to have an <iframe> in the XUL, and some JavaScript that does a CreateInstance of the nsEditorShell. The JS then tells the editorShell what iframe to observe by setting editorShell.contentWindow, before a call to loadURL. The new way is to use the new <editor> tag which is specified via XBL. This instantiates an nsEditorBoxObject in layout code, which itself creates the editorShell, and owns it. In both cases, a ton of support code in JavaScript is necessary to set up the editorShell, hook up the editorShell to the UI, and cause the URL load whose end causes the editor to get instantiated. This code lives in mozilla/editor/ui/composer/content/editor.js, much of it in EditorStartup(). An unfortunate feature of much of this JS support code is that it assumes that there is only one editorShell in the window, and so limits you to having just one editable <iframe> in a window. This definately needs to change. A related problem is that, because of this restriction, we cannot edit all frames of a frameset at the same time, nor can we deal with embedded <iframe>s in the document being edited. To solve these problems, the editor needs to live off a container at the docShell level; we need either nsIEditableDocShell, or calls on nsIDocShell to get/set an editorShell. You should also bear in mind that we might want some kind of editor at the nsIDocShellTreeOwner level, to allow for the editing of framesets. We also need the editor to be much more pluggable, so that simply putting in an <editor> tag in your XUL causes all the editorShell creation/url loading/editor instantiation to happen automagically. This means moving much of this setup code from JS into C++.

Making [nsbeta2-] and Putting on [NEED INFO] radar. PDT needs to know impact to user and risk of fix to make a call on this bug. Please let us know when you have a fix in hand so we can discuss whether to land this thing or not. Adding nsbeta3 keyword.

akkana and I spoke today about other issues. we would like to see the editor.dll split into three different components. 1. text editing 2. basic html editing 3. form and table editing.

dougt, should you own this bug?

parts of this bug are embedding releated, other parts may not be. I am going to break this bug up into a couple then see what we can do about fixing them. For now, assigning to me.

plussing.

Not enough time to do this. punting.

simon's taking on editor embedding point position.

Ongoing

Updating QA Contact

*** Bug 30507 has been marked as a duplicate of this bug. ***

Correction: Changing QA contact for the Embed API bugs to David Epstein.

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)

don't move bugs that are in the 1.0 dependency tree. sorry.

-> mjudge

EDT topembed-, not critical for a current embedding release

editor embedding not a 1.0 requirement. mozilla1.0-

changing component so this shows up in Syd's editor embedding queries

resolving as a duplicate of 157128 per editor embedding meeting *** This bug has been marked as a duplicate of 157128 ***

verified as dup