1617377 - Support compose format in 'browser.compose.begin*'

Status: RESOLVED FIXED

(Thunderbird :: Add-Ons: Extensions API, task)

Description

[Mark Banner (:standard8)]

One function that is sometimes used is pressing shift-reply to create a compose window in a different format to what you are currently.

The current API doesn't support this though.

I would propose that ComposeParams goes an extra option format. The supported values could be default, html, plaintext, oppositeDefault.

Extensions can then set it up how they want.

We'll also need the format option on beginReply.

Comment 1

[Mark Banner (:standard8)]

Having looked at the comments on bug 1613534 a bit, I'm actually wondering if I need this functionality or not. The part that Conversations has currently is the oppositeDefault (via the shift-key which probably isn't very discoverable), I might do an experiment to disable that and see if anyone complains...

Comment 2

[Mark Banner (:standard8)]

I have received the odd complaint about disabling the shift-compose functionality that Conversations provides (note: due to other TB bugs soon fixed, that version hasn't rolled out to all of Conversation users yet, so there may be more coming): https://github.com/protz/thunderbird-conversations/issues/1456

It looks generally like if the user had something like bug 140800 where they could swap between plain text and compose, then we wouldn't need an option in WebExtensions to allow for changing what happens when shift is pressed (or some other functionality).

Unfortunately I don't see that going very far at the moment, but it would be a way of allowing simpler WebExtension APIs and providing a useful option to users.

The only other option I can think of is to always force starting up in HTML mode for WebExtension APIs, and then users can at least select plain text in the delivery options. That's probably not ideal though.

Magnus, what can we do here to get a way forward? This would be useful to have a solution or at least intended route in some form to avoid needing more WebExtension experiments for this minor issue.

Comment 3

[Magnus Melin [:mkmelin]]

Hard nut to crack. I really wasn't too keen on supporting an API to switch between the two in the first place :/
We don't really have an identity API either. If we had that add-on code could figure out which parameter to use.

Comment 4

[M Lopez-Ibanez]

(In reply to Magnus Melin [:mkmelin] from comment #3)

Hard nut to crack. I really wasn't too keen on supporting an API to switch between the two in the first place :/
We don't really have an identity API either. If we had that add-on code could figure out which parameter to use.

I normally use plain-text because the HTML editor of Thunderbird does not produce nice looking messages (mismatched font-sizes, style changes in the middle of a sentence, misaligned tables or images, spurious spacing, ...) specially when replying (it seems the original email may contain CSS that messes up the HTML of the reply). However, sometimes I need to use HTML. A few use-cases:

1. I receive an HTML email with small tables or images inline. I want to comment on each table or image, so I need to use HTML to not lose tables and images while being able to reply underneath each table / image.

2. I receive a confirmation from a booking (flight, accommodation, etc) and I need to forward the email to someone else with some additional details. I need to use HTML or the forward content will be lost.

3. I need to send an email with tables and inlined images and I will spend a significant amount of time working on the formatting. I need to use HTML from the start even though 99% of the time I prefer plain-text.

Note also that the above use cases do not require converting HTML to plain-text or viceversa, which is one of the problems often raised against a button to switch from HTML<>plain-text composition. Actually, use cases 1 and 2 would prevent such conversion, since my preference would be that Thunderbird defaults to HTML in those cases to avoid losing content.

Finally, the issue reported is about the API used by Conversations. Any other entry point (except keyboard) such as right-click menu, "Message" top menu, toolbar, etc still behaves correctly for Shift+left-click.

Comment 5

[John Bieling (:TbSync)]

I think the way forward here is to fix bug 1658132 (which allows using details.isPlainText as mode selector for browser.compose.begin* and to add a defaultComposeType property to the MailIdentity:
https://thunderbird-webextensions.readthedocs.io/en/latest/accounts.html#mailidentity

WebExtension can then enforce any type and can base that decision on the users default or on the type of the message they want to use as a template.

Comment 6

[John Bieling (:TbSync)]

Attachment: bug1617377_expose_composeHtml.patch

Exposing this information allows WE to react to the default compose format and use it in the compose API to prepare body content in the desired format or even implement an option to use the opposite of the default as requested in this bug.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/6bd5e045c696
expose composeHtml in MailIdentity. r=mkmelin

Comment 8

[John Bieling (:TbSync)]

Comment on attachment 9190763 [details] [diff] [review]
bug1617377_expose_composeHtml.patch

[Approval Request Comment]
User impact if declined:
Add-on developers have to wait till next ESR to use new WebExtension API methods. As we want to move (new) developers away from the Experiment approach towards the proper WebExtension approach, improvements should be uplifted.

Testing completed (on c-c, etc.):
https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=a0811bf90663c708f20a1c65ceee55639c74ca24

Risk to taking this patch (and alternatives if risky):
None that I know of. Patch applies on current comm-esr78 (for 78.7.0)

Comment 9

[John Bieling (:TbSync)]

Remark: I have created a try run which includes all bugs I want to uplift for TB 78.7 and shows a working patch order. This bug is the 5th one:
https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=3cdff293d5d1bd77777f5da371caaa02c4b05de3

Comment 10

[Wayne Mery (:wsmwk)]

Comment on attachment 9190763 [details] [diff] [review]
bug1617377_expose_composeHtml.patch

[Triage Comment]
Approved for esr78

Comment 11

[Dave Miller [:justdave]]

Thunderbird 78.7.0:
https://hg.mozilla.org/releases/comm-esr78/rev/6966154c9c1a