66344 - [embed] implement editor extension mechanism

Status: RESOLVED WONTFIX

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

Description

[rubydoo123]

task: implement editor extension mechanism

Comment 1

[kinmoz]

Accepting bug.

Comment 2

[Simon Fraser [no longer active]]

spam

Comment 3

[Simon Fraser [no longer active]]

So here's what I think we need for this:

1. Decide what comprises an editor "extension". Something like:

     * JS file with implementation of one or more nsITransactions.
     * Properties file (localizable) containing strings
       for undo and redo actions, and the name of the extension.
     * Optional XUL/JS files for any UI that the extension needs
       to put up.
       
   Presumably these would be packed in a jar file. The properties
   file needs to live under the usual locale-specific directry
   hierarchy. Extensions may be packed with properties files for
   one or more languages.
   
   Should we allow C++ implemenations of transactions?
   
   I think an extension package should be allowed to implement any
   number of transactions (and should provide UI strings for each
   of them).

2. Choose a specified location for finding user-installed extensions.
   Probably have a per-profile, and per-installation locations.

3. Create a mechanism for finding and loading available extensions
   on composer first startup (an extensions service, probably).
   Extensions may register their transactions(s) at load time, and
   be given transaction IDs then. Maybe use RDF to build the menu
   that lists available extension transactions.

4. Hook up calling extensions' transactions to the menu items.
   Maybe allow the extensions to assign key shortcuts?
   
5. Hook up undo/redo strings.

Thoughts?

Comment 4

[Akkana Peck]

I like almost everything in Simon's proposal.

> Should we allow C++ implemenations of transactions?

I'd say probably not.  If there are things that can only be done in C++, then
we've made a mistake in our APIs.  And I don't expect there will be much demand
for C++ extensions; anyone capable of writing a C++ extension is probably
capable of submitting a patch to bugzilla and getting the code checked in.

> Maybe allow the extensions to assign key shortcuts?

That would be lovely, but I expect it'll require a redesign of the xbl
keybinding mechanism, since right now it relies on a couple of hardcoded
filenames and doesn't allow any further additions.  See bug 18508.

Comment 5

[Simon Fraser [no longer active]]

> > Should we allow C++ implemenations of transactions?
> 
> I'd say probably not.  If there are things that can only be done in C++, then
> we've made a mistake in our APIs.  And I don't expect there will be much demand
> for C++ extensions; anyone capable of writing a C++ extension is probably
> capable of submitting a patch to bugzilla and getting the code checked in.

There are reasons that people might want to implement a transaction in C++ in 
additoin to simple interface availability. The txn might be very computationally 
intensive, or even call into OS-specific services (and why not!). So allowing C++ 
extensions would, it seems to me, open up the possibility for lots of cool 
extensions which we never even thought of.

Comment 6

[Akkana Peck]

I guess you answered your own question, then. :-)

I have no objection to C++ extensions, but if they turn out to be more difficult
I don't think we should expend a lot of effort to make them work.  Or at least,
I think we should get JS extensions working first and then worry about native code.

Comment 7

[Joe Francis]

do we need the extension txns to share some commonality other than that already 
implied by nsITransaction?  If so we need an nsIEditorTransaction api.

Comment 8

[kinmoz]

I believe the answer to Joe's question is yes. We're going to need some sort of 
interface that will allow composer to query a transaction for some info like the 
strings it should display in the menus.

I want to remove UI methods from the transaction manager interfaces because 1. 
transactions should be independent from UI and 2. every app wants to get/keep 
track of UI strings etc differently.

Comment 9

[Simon Fraser [no longer active]]

-> 1.0.

Comment 10

[kinmoz]

Bulk move of mozilla1.0 bugs to mozilla.1.0.1. I will try to pull some of these
back in if I can.

Comment 11

[Kevin McCluskey (gone)]

topembed-

Kin states: You can already extend the editor via JS/C++ transactions. This bug
is about writing a mechanism that can recognize a neatly packaged (yet to be
determined format) group of files and dynamically add them to Composer's menus etc.

Comment 12

[kinmoz]

Bulk move of my milestoned bugs to Future in an effort to get my milestone lists
to reflect reality.

I will be pulling this bug back into a milestone when I can.

Comment 13

[Jaime Rodriguez, Jr.]

Corfirming topembed- [T2] per EDT triage.

Comment 14

[Makoto Kato [:m_kato]]

old bug.  down to P3

Comment 15

[Andrei Purice]

Hey Makoto,
Is this issue still reproducing or should we close it?

Comment 16

[Makoto Kato [:m_kato]]

This bug is old Netscape-era issue. So we should mark as WONTFIX.