1590121 - API to interact with the message being drafted in a compose window

Status: RESOLVED FIXED

(Thunderbird :: Add-Ons: Extensions API, enhancement, P2)

Description

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

We have a composeAction, which is great. Though it doesn't seem there is any way to otherwise interact with the message that is being drafted. A few use cases:

1. Add/remove recipients, change the subject, change sender identity
2. Insert stuff into the html editor
3. Changing styling of selected text in the html editor
4. Adding attachments
5. Changing the state of some of the other formatting buttons (bold, indent, font type, etc)
6. Force saving the message (draft, template, etc)
7. Setting other properties (return receipt, DSN, plain text, etc)
8. Event when message is sent with an option to cancel (this might better be a more general mailRequest, akin to webRequest)

Given the scope above I'm making this a meta bug. I've sorted the above by suggested priority. I think we should be selective how much access we are giving to the editor html. Full access would allow for anything, but could potentially be brittle. Part of the work would be figuring that out.

Comment 1

[Alexander Bergmann]

My add-on Mail Merge also needs quite a lot of the mentioned information in the Message Compose Window. At the moment most of the required information is gathered through gMsgCompose in the Message Compose Window. See: /content/overlay.js and /content/utils.js in Mail Merge 6.1.0.

When you develop such an API, please keep Mail Merge and its use-case in mind, thanks!

Comment 2

[Geoff Lankow (:darktrojan)]

I'm assigning myself this, since I already started something very similar for bug 1532528.

Comment 3

[Volker]

This is really important and mandatory for us, too. We stopped our Thunderbird Add-On for now. But if this functionality is coming back in WebExtensions, I consider re-writing our Add-On for the new Thunderbird. Please keep this bug updated.

Comment 4

[Geoff Lankow (:darktrojan)]

Attachment: 1590121-compose-details-1.diff

Okay, I've been looking at this long enough. Here's a patch to do the minimum: change to/cc/bcc/reply-to headers and the subject. We can build on that.

Comment 5

[Geoff Lankow (:darktrojan)]

I don't really like the names compose.getState and compose.setState, so if anybody has a better suggestion…

Comment 6

[Volker]

Thanks for taking care about this feature. How about setAttributes/getAttributes? Will cover all possible aspects of an email and maybe fits better than "state" (which sounds like some on/off value or flag to me).

PS: Not sufficient for me yet, need access to read/add/remove attachments and read/replace ascii/html body, too.

Comment 7

[Magnus Melin [:mkmelin]]

Comment on attachment 9124422 [details] [diff] [review]
1590121-compose-details-1.diff

Review of attachment 9124422 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good, mainly some documentation nits.

::: mail/components/compose/content/MsgComposeCommands.js
@@ +3587,2 @@
>   */
> +function GetState() {

getComposeDetails perhaps?

@@ +3597,1 @@
>    msgCompFields.subject = subject;

could inline the subject, since it's only used once

@@ +3603,5 @@
> +/**
> + * Updates the UI to match newValues.
> + *
> + * @param {Object} newValues - New values to use. Values that should not change
> + *                             should be null or not present.

Would prefer the wrapping style like

	
 * @param {Object} fields - New comp fields to use. Values that should not change
 *    should be null or not present.

Let's also add
  @param {string} [fields.subject]
  @param {string} [fields.to]
  @param {string} [fields.cc]
  @param {string} [fields.bcc]
  @param {string} [fields.replyTo]
  @param {string} [fields.newsgroups]
  @param {string} [fields.followupTo]

... and fix the doc here - https://searchfox.org/comm-central/rev/4656a6fc05593b508b8a18928d9c9efebe3a7958/mail/components/compose/content/addressingWidgetOverlay.js#99 - it's not an array, but an object

@@ +3617,5 @@
> +}
> +
> +/**
> + * Handles message sending operations.
> + * @param msgType nsIMsgCompDeliverMode of the operation.

@param {nsIMsgCompDeliverMode} mode - The delivery mode of the operation.

::: mail/components/extensions/parent/ext-compose.js
@@ +78,5 @@
>      params.originalMsgURI = msgHdr.folder.getUriForMsg(msgHdr);
>    }
>    params.type = type;
>    if (composeParams) {
> +    for (let field of ["to", "cc", "bcc", "replyTo"]) {

could you add newsgroups and followupTo as well?

@@ +174,5 @@
> +      if (
> +        tab.nativeTab.location.href !=
> +        "chrome://messenger/content/messengercompose/messengercompose.xhtml"
> +      ) {
> +        throw new ExtensionError("Not a valid compose window");

would include the tab.nativeTab.location.href in the message for better debugging

::: mail/components/extensions/test/browser/head.js
@@ +175,5 @@
> + * Check the headers of an open compose window against expected values.
> + *
> + * @param {Object} expected - A dictionary of expected headers:
> + *                            * to, cc, bcc, replyTo as an array of addresses
> + *                            * subject as a string

jsdoc style for these, like described above

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/7054e74ce11b
API to interact with the message being drafted in a compose window. r=mkmelin

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/e5e31792c53c
follow-up - Remove invalid schema entries. rs=me DONTBUILD

Comment 11

[Wouter]

I just spent a few hours looking into what it would involve adding HTML / Text and attachment support to this feature. As far as I can tell this is handled by the gMsgCompose service and thus not easily extended. If someone could tutor me to help in this regard that would be great. I have some paid time available to implement this and get it upstream.

The current situation is that extensions like mine are facing the imminent deprecation of XUL, and a not concrete hope that WebExtensions will support the functionality that I need maybe before the time of that deprecation. Personally I would rather have that Enigmail not be integrated natively, but that Enigmail would also have to use WebExtensions like every other extension. That way we would have our desired functionality sooner.