35639 - embedding: Need to design/ implement Editor Embedding APIs

Status: VERIFIED DUPLICATE of bug 157128

(Core :: DOM: Editor, defect, P3)

Description

[travis]

Need to implement embedding APIs for editor.

Comment 1

[shrirang khanzode]

Sorry for the spam, changing QA contact.

Comment 2

[Simon Fraser [no longer active]]

Grab

Comment 3

[rubydoo123]

setting to m18 for now

Comment 4

[Judson Valeski]

nom. doug should you get this?

Comment 5

[Simon Fraser [no longer active]]

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++.

Comment 6

[Jay Patel [:jay]]

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.

Comment 7

[Doug Turner (:dougt)]

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.

Comment 8

[Simon Fraser [no longer active]]

dougt, should you own this bug?

Comment 9

[Doug Turner (:dougt)]

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.

Comment 10

[Judson Valeski]

plussing.

Comment 11

[Doug Turner (:dougt)]

Not enough time to do this.  punting.

Comment 12

[Judson Valeski]

simon's taking on editor embedding point position.

Comment 13

[Simon Fraser [no longer active]]

Ongoing

Comment 14

[Paul Wyskoczka]

Updating QA Contact

Comment 15

[Simon Fraser [no longer active]]

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

Comment 16

[Michael Dunn]

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

Comment 17

[Asa Dotzler [:asa]]

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)

Comment 18

[Asa Dotzler [:asa]]

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

Comment 19

[Simon Fraser [no longer active]]

-> mjudge

Comment 20

[saari (gone)]

EDT topembed-, not critical for a current embedding release

Comment 21

[Asa Dotzler [:asa]]

editor embedding not a 1.0 requirement. mozilla1.0-

Comment 22

[Kathleen :Brade]

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

Comment 23

[Kathleen :Brade]

resolving as a duplicate of 157128 per editor embedding meeting

*** This bug has been marked as a duplicate of 157128 ***

Comment 24

[David Epstein]

verified as dup