Open Bug 539299 Opened 15 years ago Updated 2 years ago

Build an experimental add-on to author emails with a third-party web composition toolkit editor

Categories

(Thunderbird :: Message Compose Window, enhancement)

enhancement

Tracking

(Not tracked)

ASSIGNED

People

(Reporter: davida, Assigned: protz)

References

(Blocks 1 open bug)

Details

(Whiteboard: [patchlove])

Attachments

(1 file)

There are plenty of Javascript-implemented toolkits which have been authored for blog and wiki editing, some of which could be used in an add-on to provide an alternative authoring tool compared to the built-in editor code.

It'd be really interesting to have an add-on that:

1) used one of these editors (CKeditor, or other -- license issues TBD)
2) hooked into the appropriate bits of Thunderbird to be invoked by composition commands (new, reply, forward, etc.)

and that various folks could give comments on.  

Maybe this doesn't belong in this component, but I'm not sure where else to track this.
I integrated FCKeditor (the previous version of CKEditor) in an Add-on for Firefox: https://addons.mozilla.org/en-US/firefox/addon/6147

I planned to update the editor to the new version as soon as I have time and I can verify that there are no big issues with the new code, this might not be too helpful to integrate into Thunderbird, but this is a really interesting idea.
Assignee: nobody → jonathan.protzenko
Status: NEW → ASSIGNED
OS: Mac OS X → All
Hardware: x86 → All
Version: 3.0 → 3.1
Attached patch WIPSplinter Review
David, the situation is as follows: I'm using a CKEditor instance inside a tab, and the code from nsMsgSend.cpp needs to prepare the message properly before sending. This implies getting the list of DOM Nodes that are images/objects/whatever in the editor, and creating inline MIME attachments to send them alongside with the message.

nsMsgSend relies on a nsIEditorMailSupport to pass it a list of image/object/whatever DOM Nodes from the compose window, so that it can get their contents, encode them as attachments, and replace the associated hrefs with src="cid:PART-ID" URLs.

The regular code does this through nsMsgCompose.cpp. It is initialized with an associated compose window, and nsMsgCompose.cpp makes the assumption that that window is the "classic" compose window, gets the associated editor, runs whole sorts of dark voodoo on the editor regarding encodings and stuff, and finally, when the time has come to send the message, it passes the associated nsIEditor instance to nsMsgSend.cpp.

The function that passes the control from nsMsgCompose.cpp over to nsMsgSend.cpp is CreateAndSendMessage.

As you probably guessed already, I don't want/need to pass the nsIEditor to nsMsgCompose.cpp as I'm using a totally different editor. However, I do want nsMsgSend.cpp to query me so that I can pass it a list of DOM nodes that need processing.

I figured out the simplest way to do that would be to patch somehow these two files to allow a "fake editor" to be passed to nsMsgSend.cpp, by adding an extra argument to CreateAndSendMessage (from nsMsgCompose.cpp).

Any thoughts?
Attachment #470719 - Flags: feedback?(bienvenu)
minor comment: you'd need to rev the ID of the interface you change.
(In reply to comment #2)
> 
> I figured out the simplest way to do that would be to patch somehow these two
> files to allow a "fake editor" to be passed to nsMsgSend.cpp, by adding an
> extra argument to CreateAndSendMessage (from nsMsgCompose.cpp).
> 

I think any <editor> should supports nsIEditor (and all other interfaces like selection, etc), for compatibility. Otherwise many extensions will stop working.

CKEditor may be used as implementation, but existing interfaces should be not changed.

BTW, "Javascript-implemented" sounds a bit slow... I hope it will not hang application with larger documents.
Comment on attachment 470719 [details] [diff] [review]
WIP

an other option would be to add the ability to set the editor directly in nsIMsgCompose.idl as an attribute.
Attachment #470719 - Flags: feedback?(bienvenu) → feedback+
Even if I only change a readonly attribute to a readwrite one, I still need to renew the UUID of the interface, right? I had hoped I could do this without changing interfaces but it looks kinda hard right now.

Your solution has the advantage of not breaking everyone who uses SendMsg, I'll try to use that instead.
@comment #1
The mentioned XPI seems to be valid for FX/SM only.

Any idea how to add it to Thunderbird?
  NB:  This bug is for Product: Thunderbird / Version 3.1
If I didn't missed anything ...

Günter
Version: 3.1 → Trunk
let's put this where more people care about compose
Blocks: 361619
Severity: normal → enhancement
Component: General → Message Compose Window
QA Contact: general → message-compose
Summary: Build an experimental add-on to author emails with a third-party web composition toolkit → Build an experimental add-on to author emails with a third-party web composition toolkit editor
Ehsan Akhgari is working on a fix to the editor.
https://bugzilla.mozilla.org/show_bug.cgi?id=590640
May be this bug depends on that.
This bug seems to have gotten a lot of attention, probably due to Timo Pietilä's post on m.d.a.t. First of all, thanks for your interest, I'm glad so many of you care about this feature! I've blogged about this http://mozillalabs.com/messaging/2010/09/03/2756-bugs-found/ so for all of you who are interested in discussing this feature, I suggest we all chat about it over at Mozilla Labs' blog. This will allow us to keep this bug focused on the technical discussion about the patches I'm working on. Thanks!
I think that this bug will never get solved. After getting some attention back
in august and september, now everything is again sleeping.
Work Jonathan Protzenko is at a standstill since September 10
https://github.com/protz/Compose --
https://bugzilla.mozilla.org/show_bug.cgi?id=539299
And the same happen to Ehsan Akhgari
https://bugzilla.mozilla.org/show_bug.cgi?id=590640
Malix: I understand that you're frustrated that some bugs aren't fixed as quickly as you might hope.  That's entirely valid, and I suspect that frustration is shared by others as well.

That said, both Protz and Ehsan are doing (and have done) a lot of great work for Thunderbird.  Personally singling them out to vent your frustration is inappropriate, and is certain to make them less inspired to volunteer their own time to fix Thunderbird bugs (neither of them are being paid for the help they're so kindly extending).  I believe you owe them both an apology.

Please review <https://bugzilla.mozilla.org/page.cgi?id=etiquette.html> before commenting further in Bugzilla bugs.
When next version of this plug-in is planned? I'm waiting for ending my test with Ehsan Akhgari patch https://bugzilla.mozilla.org/show_bug.cgi?id=590640#c19 

Thanks
Massimo
Sometime in the upcoming week. I've been busy with other extensions and different areas of Thunderbird, but I'm about to release a better version of the addon, that's compatible with the upcoming 3.3a3, and possibly better.

I insist that this is an experiment, so this is not bound to replace the editor anytime soon. So this experiment is not related to the fix in bug 590640. Ehsan is probably busy fixing Firefox 4 blockers, but we might see some action on bug 590640 after Firefox 4 is release, I guess.
(In reply to comment #14)
> Sometime in the upcoming week. I've been busy with other extensions and
> different areas of Thunderbird, but I'm about to release a better version of
> the addon, that's compatible with the upcoming 3.3a3, and possibly better.
> 
> I insist that this is an experiment, so this is not bound to replace the editor
> anytime soon. So this experiment is not related to the fix in bug 590640. Ehsan
> is probably busy fixing Firefox 4 blockers, but we might see some action on bug
> 590640 after Firefox 4 is release, I guess.

Hi Jonathan,

thanks for your timely and accurate response. I hope that we can get a quick solution to this bug. Although by the time I temporarily fix the problem using the QuoteAndComposeManager. extension

Kind regards
Massimo
(In reply to comment #14)
> I insist that this is an experiment, so this is not bound to replace the editor
> anytime soon. So this experiment is not related to the fix in bug 590640. Ehsan
> is probably busy fixing Firefox 4 blockers, but we might see some action on bug
> 590640 after Firefox 4 is release, I guess.

I've added bug 590640 to the to-do list I have for things after Firefox 4.
For all of you following this topic, I've posted an update to https://groups.google.com/forum/#!topic/mozilla-labs/0MGAJQLtzKc/discussion
Whiteboard: [patchlove]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: