Bugzilla

This is the documentation for the new behaviour, taken from the `ComposeDetails` definition:

* body : The HTML content of the message. Ignored by `setComposeDetails`, if used on a plain text composer. If only `body` is specified when used with `beginNew`, `beginReply` and similar functions, an HTML message will be created. The recommended usage is to always specify both (`body` and `plainTextBody`) and use `isPlainText` to select the compose format, or use the users default compose format.

* plainTextBody : The plain text content of the message. Ignored by `setComposeDetails`, if used on an HTML composer. If only `plainTextBody` is specified when used with `beginNew`, `beginReply` and similar functions, a plain text message will be created. The recommended usage is to always specify both (`body` and `plainTextBody`) and use `isPlainText` to select the compose format, or use the users default compose format.

* isPlainText : Wether the message is an HTML message or a plain text message. Can be used to specify the message format in `beginNew`, `beginReply` and similar functions. It is however not possible to change the compose format with `setComposeDetails`. Note: Using `isPlainText` together with a single but conflicting body type (e.g.: `isPlainText` = `true` and `body` is set but not `plainTextBody`) will cause an exception.

I did not alter the behaviour, that `setComposeDetails()` cannot change the format, because that would require a lot of core changes, as it is really not possible, even for Thunderbird itself. Creating a bug in core for that general capability might be a good idea, I can then pick up the feature for the WebExt API. But `setComposeDetails()` now ignores `details.isPlainText` and picks what it needs, either body or plainTextBody - instead of throwing. This could leave the user with an empty composer, if the developer only specified the "wrong" body type. But I decided to not throw in that case anymore, to keep the rules simple, which is just "body: Ignored by `setComposeDetails`, if used on a plain text composer." (and its counterpart).

This is the documentation for the new behaviour, taken from the `ComposeDetails` definition:

* body : The HTML content of the message. Ignored by `setComposeDetails`, if used on a plain text composer. If only `body` is specified when used with `beginNew`, `beginReply` and similar functions, an HTML message will be created. The recommended usage is to always specify both (`body` and `plainTextBody`) and use `isPlainText` to select the compose format, or use the users default compose format.

* plainTextBody : The plain text content of the message. Ignored by `setComposeDetails`, if used on an HTML composer. If only `plainTextBody` is specified when used with `beginNew`, `beginReply` and similar functions, a plain text message will be created. The recommended usage is to always specify both (`body` and `plainTextBody`) and use `isPlainText` to select the compose format, or use the users default compose format.

* isPlainText : Wether the message is an HTML message or a plain text message. Can be used to specify the message format in `beginNew`, `beginReply` and similar functions. It is however not possible to change the compose format with `setComposeDetails`. Note: Using `isPlainText` together with a single but conflicting body type (e.g.: `isPlainText` = `true` and `body` is set but not `plainTextBody`) will cause an exception.

Regarding Comment 4: I did not alter the behaviour, that `setComposeDetails()` cannot change the format, because that would require a lot of core changes, as it is really not possible, even for Thunderbird itself. Creating a bug in core for that general capability might be a good idea, I can then pick up the feature for the WebExt API. But `setComposeDetails()` now ignores `details.isPlainText` and picks what it needs, either body or plainTextBody - instead of throwing. This could leave the user with an empty composer, if the developer only specified the "wrong" body type. But I decided to not throw in that case anymore, to keep the rules simple, which is just "body: Ignored by `setComposeDetails`, if used on a plain text composer." (and its counterpart).