html signature support

[GTP95]

As others have pointed out when this project was hosted on Google Code, would be really nice if you add html support in signatures too.

[Zeitwaechter]

bump

It doesn't look that good if I'm writing business e-mails without HTML signatures.

You know? Your Application is so superb! But it's clearly lacking this one feature.. :(

[jurekam]

bump

Any progress on this? This is a "given" option that is available in all other email clients, no matter what the platform. Please provide an update! Thank you.

[GTP95]

Jurekam, do you know a free Android email client that supports html signature? If yes can you please tell me what it is?

[cketti]

This is a technical issue tracker, not a discussion forum. If you don't have technical details to add please use the mailing list.

In volunteer-run open source projects the answer to the question "when will it be ready?" is always "when it's done". I will delete further inquiries of this kind as they only add noise and no value.

[R2116]

Isn't this rather a bug? You aldready distinguish between HTML/ no HTML within the code but it doesn't work
https://github.com/k9mail/k-9/blob/master/k9mail/src/main/java/com/fsck/k9/message/TextBodyBuilder.java#L189

[philipwhiuk]

No its not. A bug is something that doesn't work. Not something that is missing. We don't supporting writing HTML formatted emails and signatures. That's not a bug.

That code does work. It converts plaintext into HTML formatted plain text. i.e. it replaces new lines with <br>'s

That doesn't mean you can use HTML formatting to write formatted text (i.e., bold, underline, links) which is what this bug is about.

This bug is either:

• the implementation of an editor to write a signature (selecting text and bolding it, inserting links)
• or an option to write HTML tags directly in the signature code.

The second would be a bit ugly. The first is a lot of work.

In any case, bug vs enhancement is bikeshedding. It won't affect the speed at which it gets implemented.

[nose-gnome]

Is there a reason this hasn't happened yet? Is there something making this difficult to implement, if not, then I might be able to try and open a pull request to fix this, as this has been extremely annoying for me.
Unless it's a lot of work to implement.

[nikkyandrei]

i agree with @nose-gnome in this moment i consider the biggest thing that is missing , i agree to write my entire HTML and use to external source for images in signatures . is frustrating that the body support HTML but signature not

Thank you and keep up the good work

[derWalter]

I am really here in 2024 to find out this is not a thing yet.

[kewisch]

Welcome to 2024 ;-) We'd love to have this as well, but there is only so much we can do at once. If someone wants to dive into contributing we're happy to help.

In the meanwhile, I think the best way to indicate your support is upvoting https://connect.mozilla.org/t5/ideas/allow-html-signatures-in-k-9-mail/idi-p/28983 . We use connect as one of many source for our roadmap.

[BRKsays]

Would it be possible to consider an incremental approach for implementing HTML signature support? Perhaps starting with image support first, so users can include logos or banners in their signatures. This would be a great intermediate step, especially for professionals who use branding in their communication.

Further down the line, a rich text editor for formatting (like bold, italics, and different fonts) could be gradually introduced. I think this step-by-step process might make development and testing easier, while providing immediate value to users.

Just a suggestion. I realise this is a volunteer work. Since this is a much requested feature maybe this can be tackled in a different way without increasing workload too much.

[Retroguru]

Please add this feature. I was about to switch from Spark to Thunderbird. Now I am hesitating to finish the setup and will keep my old email client.

[lolcabanon]

• the implementation of an editor to write a signature (selecting text and bolding it, inserting links)
• or an option to write HTML tags directly in the signature code.

The second would be a bit ugly. The first is a lot of work.

Hey, in the desktop version, you just check a box ([ ] Use HTML) and drop your HTML code in the box and It Works! I know the app should validate the code and protect against injection (which is the hard part I guess?) but I don't get what's "ugly" about that?

This is currently the only thing that prevent me from switching from Spark to Thunderbird Mobile for my work emails.

[PhilippSchlesinger]

In Thunderbird desktop version, you can attach a signature from (whether paintext or html, even an image is possible).
This SUMO article even describes how to create a html signature with the Thunderbird composer.

In the first step it could be possible to just source the very same signature from a file on Thunderbird for Android as well.
This feature is requested as an enhancement in #6138.

[ndekross]

The easiest thing in terms of UI would be allowing to pick an html file

[ttes0]

This, an html signature, is the biggest issue, which prevents my using the mobile thunderbird/k-9 email for business use, and hence personal use. It's a necessary feature to implement if a wider adoption or a more serious use of your mobile client is sought.
Unless, some form of non-html text formatting could be implemented.

[nikkyandrei]

I'm wainting for some months for a way to add a signature at least one method for beginning :

• write a html code in a input (i will copy paste it)
• add a link that contain the html code
• add a file that contain the html code

And i still waiting ...
bare minimum ... tags like : table,tr,td,span,div,a,img, and support for attributes: style , href (for "a" tag) and src (for "img" tag) the rest of things can be stripped

[Paladinleeds]

So I wouldn't know how to implement it I'm afraid, but this is definitely something missing. I tend to have a three line signature, with the first line saying "Kind regards" in normal text, then my name in bold, then my pronouns in italics. It's consistent across the board. Hopefully someone can make this happen, even if we have to write the html ourselves in the editor (I tried the HTML version and that just put the HTML tags in plain text, not what I was after unfortunately!), and while we're on the subject of it, perhaps allowing us to use a vCard as a signature as well (like desktop Thunderbird)?

If this one thing can be addressed, I would absolutely switch to Thunderbird on Android in a heartbeat (I love it on desktop, and I'm already using Firefox too). I'm gonna see how I get on with it for now using plain text signatures but still, hopefully this can be addressed! It's a great app otherwise.

[kewisch]

Working on an intermediate approach suffers from the same issue as working on the complete approach, there is only so much we can do and this isn't immediately on our roadmap at the moment. I appreciate that folks want to share their use cases, and I'd love for folks to be able to switch to Thunderbird because of this, but I think the best way to signal your support is a simple no-comment upvote on the linked connect idea: https://connect.mozilla.org/t5/ideas/allow-html-signatures-in-k-9-mail/idi-p/28983

I'm going to close this issue - not because it is not going to happen - but because we're looking to collect feature requests on Mozilla Connect so we can focus on active development on this bug tracker.

[Julien-Delavisse]

All right, what next?

This feature is already the most requested on Connect ...
https://connect.mozilla.org/t5/ideas/idb-p/ideas/label-name/thunderbird%20android/tab/most-kudoed

How is the roadmap drawn up?

The features missing from the mobile version of Thunderbird are pretty obvious to a user after a few days' use:

• HTML signatures
• send later
• better distinction between accounts
• calendar support

And that's ... the most requested features on Connect ...

You don't need to collect more requests.
You need to keep the issues of those requests open 😉

Sorry I can't help with their developments, I have no mobile skills.

[BRKsays]

I'm sorry but it is very disappointing to see the way this is being handled.

Adding to what @Julien-Delavisse already pointed out, what's the point of all this GitHub issues, feature requests on mozzilla connect if at the end of the day the end user doesn't have a say on the roadmap of this project?

I mean let this sink in, this issue/feature request is the most liked feature request over there and even then it doesn't end up in the roadmap? What is the criteria then? Who decides what goes in and what not? The end users, the patrons, the devs or some guy in the suit?

[kewisch]

Regarding Connect vs bugtracker, the more issues that are open on the bugtracker the harder it is to focus. Again, closing this issue doesn't mean anything about the decision on this feature. But having it open in two places means more cognitive load.

The 2025 roadmap is not yet completely laid out, please cut us some slack and don't assume the worst. This is an open source project, so for sake of argument, everyone can decide what their own roadmap looks like, and become a contributor. When I blog about the MZLA goals for this year I'll certainly go into a bit of detail on what topics I selected and why. I don't regularly wear suits btw.

Connect is one source of product roadmap decisions. I also look at the issue tracker, reviews, conceptual direction, wishes from patrons, among others. To put things into relation, the ~100 people that have voiced their support represent about about 0.00054% of Thunderbird for Android release users. Could a top-voted feature be left out in the future? Possibly. Could it also be included? Definitely. It’s all about balancing community input with practical decisions and creating coherence in direction.

[Julien-Delavisse]

I agree with you on several points.

It's an open-source project, so if you want to have more say, all you have to do is contribute to the code. (Still, you need to have the skills, the time and the modifications to be accepted).

Closing the most requested issues sends the wrong signal to the community.

Suggesting that we express our opinions on Connect, before saying that it only represents 0.00054% of users, what do you think we understand when we read this?

Not to mention that this very small percentage is possibly the noisy minority of silent users who have the same problems. Not to mention the non-users who are waiting for these features before switching to Thunderbird.

This may not be the place for it, but it's hard not to make the connection with all the features removed and added to Firefox that don't meet the demands of its user base.

Perhaps I'm too persimistic, hoping that time will prove me wrong 😉

Looking forward to reading your blog post

[kewisch]

I think you are being too pessimistic and I hope I can prove you wrong :-) I need as many signals as I can reasonably process to make a good decision on what we will be working on, so even if it is only 100 users, it still helps. You are correct there may be many more users out there missing the feature, or users just waiting to switch because of this. What I wanted to express is merely that product roadmaps are not simply taking the top voted issues and calling it a day.

I can't speak for Firefox since this is completely different company to MZLA. But no matter where you are, people are human and can make smart decisions and wrong decisions. Sometimes even smart decisions that turn out to be wrong ;-)

[ttes0]

To put things into relation, the ~100 people that have voiced their support represent about about 0.00054% of Thunderbird for Android release users.

To put things into perspective (mine), the statement that only "about 0.00054% of Thunderbird for Android release users" voicing their support for an 'html signature' being implemented seems so very outside of reality thinking, when one considers the extra effort and knowledge that an 'average user' would need to expand && possess to actually voice their support of this feature on github, i.e. create account, search issues, etc
Most users -- the average users -- will just move on to another email client offered in their mobileOS store, a client which offers what their business or personal needs require.
So, like with Firefox, I feel that perhaps sometimes the developers fail to pay attention to their somewhat knowledgeable user base, when it comes to introducing and/or eliminating features (e.g. usability)