feature request: "message headers" dialog: make 'show original' a clickable link

unknown commented

2026-09-02 20:09:29 +00:00

The original description was not recovered.

Referenced by commits

coffey-labs/ihasmail@b10ce2f9dd 2026-09-02 Make "Show original" in the headers dialog the action, not a description

_{Rebuilt from: notification email, session transcript.}

*The original description was not recovered.* **Referenced by commits** - coffey-labs/ihasmail@b10ce2f9ddac 2026-09-02 Make "Show original" in the headers dialog the action, not a description <sub>Rebuilt from: notification email, session transcript.</sub>

jcoffey-dev commented

2026-09-02 20:25:14 +00:00

Owner

Done, in #237 — live now as 2026.9.2+pr237. "Show original" in the headers dialog is now the action rather than a description of one. Clicking it closes the headers and opens the original, so it reads as going deeper rather than as stacking a second window on top.

You're right about the principle and it's worth saying so: a hint that names a feature and leaves you to hunt for it is doing half a job. It cost about ten minutes and I'd never have got round to it on my own, because it never looks like the most important thing on any given day.

It found a bug on the way, which is the part I'd flag. To make the phrase a link I needed the style that already exists for buttons-that-read-as-text — and found it was scoped to the compose window's To/Cc labels. Two places outside that scope were already using it, including the trusted-domain list in Privacy settings, and both have been rendering as ordinary button chrome sitting in the middle of a sentence. Unscoping the rule fixes those too. So the polish request turned up a small piece of existing scruffiness, which is a fair trade.

One implementation note in case you ever look: the sentence is kept whole for translation with the button interpolated into it, rather than being chopped into "Use" + button + "for the complete raw message". Languages that put the verb elsewhere can move the hole; they can't reassemble two fragments.

I have a feeling ihasmail is about efficient usage, otherwise you would probably not care about the keyboard shortcuts that much

That's a fair read, and g o from your other issue went out an hour ago if you want to try it.

Done, in #237 — live now as `2026.9.2+pr237`. "Show original" in the headers dialog is now the action rather than a description of one. Clicking it closes the headers and opens the original, so it reads as going deeper rather than as stacking a second window on top. You're right about the principle and it's worth saying so: a hint that names a feature and leaves you to hunt for it is doing half a job. It cost about ten minutes and I'd never have got round to it on my own, because it never looks like the most important thing on any given day. **It found a bug on the way, which is the part I'd flag.** To make the phrase a link I needed the style that already exists for buttons-that-read-as-text — and found it was scoped to the compose window's To/Cc labels. Two places outside that scope were already using it, including the trusted-domain list in Privacy settings, and both have been rendering as ordinary button chrome sitting in the middle of a sentence. Unscoping the rule fixes those too. So the polish request turned up a small piece of existing scruffiness, which is a fair trade. One implementation note in case you ever look: the sentence is kept whole for translation with the button interpolated into it, rather than being chopped into "Use" + button + "for the complete raw message". Languages that put the verb elsewhere can move the hole; they can't reassemble two fragments. > I have a feeling ihasmail _is_ about efficient usage, otherwise you would probably not care about the keyboard shortcuts that much That's a fair read, and `g` `o` from your other issue went out an hour ago if you want to try it.

mbunkus commented

2026-09-02 21:06:44 +00:00

…rather than being chopped into "Use" + button + "for the complete raw message"…

Yeah, I know that problem rather well. In my own projects that feature translations or internationalization in general I only use format strings as they can be translated just fine, or include static markup in the string to translate (though the latter requires more work for both the translators & developers who have to verify the markup survives the translator's job).

> …rather than being chopped into "Use" + button + "for the complete raw message"… Yeah, I know that problem rather well. In my own projects that feature translations or internationalization in general I only use format strings as they can be translated just fine, or include static markup in the string to translate (though the latter requires more work for both the translators & developers who have to verify the markup survives the translator's job).

mbunkus commented

2026-09-02 21:14:05 +00:00

side note, I keep getting questions asking for a comparison to bulwark, so I posted this today, what do you think?

Just finished reading it. I think it's very fair, and rather in-depth — but keep in mind that I'm not that deeply familiar with Bulwark Mail yet. I had started using it before getting to know ihasmail, and I have filed a couple of bug reports against it. But seeing how quickly you move forward with ihasmail, I've spent most of my time since on ihasmail (testing, reporting bugs & feature requests, getting my colleagues up to speed, and using it for every-day mail, at least for my private account which I've migrated to Stalwart+ihasmail).

I like that you really try to point out all the positives in both projects, makes it feel less of a "here's why ours is better" page so typical in feature comparisons of commercial projects.

What tips the scale in favor of ihasmail for me personally are:

speed of implementation at the moment
the fact that you've fixed the "show timestamps in local date/time format, make it configurable" in the first place & so fast at that while the very same bug has been open in Bulwark Mail for several months now
that ihasmail has always had free/busy information during event scheduling, something Bulwark Mail doesn't seem to have (but I might be wrong here, like I said, haven't gone that deep into it yet)
contains all the features both my own company and our usual customers usually want, meaning Bulwark's plugin system isn't that big of a win in our situation

The choice didn't get down to deployment method for me, but to those other substantial reasons.

Those points aren't meant for inclusion in the comparison! They're just background information.

> side note, I keep getting questions asking for a comparison to bulwark, so I posted this today, what do you think? Just finished reading it. I think it's very fair, and rather in-depth — but keep in mind that I'm not that deeply familiar with Bulwark Mail yet. I had started using it before getting to know ihasmail, and I have filed a couple of bug reports against it. But seeing how quickly you move forward with ihasmail, I've spent most of my time since on ihasmail (testing, reporting bugs & feature requests, getting my colleagues up to speed, and using it for every-day mail, at least for my private account which I've migrated to Stalwart+ihasmail). I like that you really try to point out all the positives in both projects, makes it feel less of a "here's why ours is better" page so typical in feature comparisons of commercial projects. What tips the scale in favor of ihasmail for me personally are: - speed of implementation at the moment - the fact that you've fixed the "show timestamps in local date/time format, make it configurable" in the first place & so fast at that while the very same bug has been open in Bulwark Mail for several months now - that ihasmail has always had free/busy information during event scheduling, something Bulwark Mail doesn't seem to have (but I might be wrong here, like I said, haven't gone that deep into it yet) - contains all the features both my own company and our usual customers usually want, meaning Bulwark's plugin system isn't that big of a win _in our situation_ The choice didn't get down to deployment method for me, but to those other substantial reasons. Those points aren't meant for inclusion in the comparison! They're just background information.

mbunkus commented

2026-09-02 21:17:10 +00:00

Oh, I just noticed a minor thing you might improve in the list: the order of the two columns depicting the two projects change. They start out "ihasmail left, Bulwark Mail right" (in sections "The one difference the rest follows from" & the first part of "Side by side") but swap in the "Which one to pick" section. This confused me at first as I didn't read the section's introductory lines too carefully & was then confused by the "OIDC/OAuth2" argument being on the left.

Oh, I _just_ noticed a minor thing you might improve in the list: the order of the two columns depicting the two projects change. They start out "ihasmail left, Bulwark Mail right" (in sections "The one difference the rest follows from" & the first part of "Side by side") but swap in the "Which one to pick" section. This confused me at first as I didn't read the section's introductory lines too carefully & was then confused by the "OIDC/OAuth2" argument being on the left.

feature request: "message headers" dialog: make 'show original' a clickable link #236