Bug 393421 - No ability to hide the HTML Message Status Bar
Summary: No ability to hide the HTML Message Status Bar
Status: CLOSED INTENTIONAL
Alias: None
Product: kmail2
Classification: Applications
Component: UI (show other bugs)
Version: 5.8.0
Platform: Other Linux
: NOR normal with 202 votes (vote)
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
: 393473 393595 408727 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-04-23 11:25 UTC by Cristian Adam
Modified: 2022-02-27 00:17 UTC (History)
38 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
KMail HTML Status Bar (59.03 KB, image/png)
2018-04-23 11:25 UTC, Cristian Adam
Details
Alternate UI for the distracting and intrusive html bar (38.52 KB, image/png)
2018-09-27 14:09 UTC, Sudhir Khanger
Details
html white bar (37.65 KB, image/png)
2019-01-25 10:42 UTC, Sudhir Khanger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Cristian Adam 2018-04-23 11:25:53 UTC
Created attachment 112189 [details]
KMail HTML Status Bar

After upgrading to KMail 5.8 on KDE Neon I have noticed a back "HTML Message" vertical button bar in the middle of the screen.

This is very distracting and it brings very little functionality. Almost all my email messages are HTML anyway. And if I click on it nothing happens in the email view panel.

See the attached screen shot.
Comment 1 PK 2018-04-23 12:07:22 UTC
+1
Comment 2 Laurent Montel 2018-04-23 12:39:01 UTC
you can't to disable it as new user didn't know this feature.
So now it's by default.
Regards
Comment 3 Cristian Adam 2018-04-23 12:44:09 UTC
What do you mean by "you can't to disable it as new user didn't know this feature." ?

As a user I don't need to switch between HTML and plain-text. 

I really do care about the vertical space used by the bar, so I need that bar gone.

I don't think is too much to ask to have this user configurable in the settings.
Comment 4 PK 2018-04-23 13:31:27 UTC
Kmail is growing into a real quality application that looks good too. But now the beautiful looks are being hit by this html-status-bar that makes a lot of noise about (in my opinion) not so much.
If someone finds the message of the bar important that's ok. But I find it more important that kmail is comforting to the eyes. And is is!
I would very much appreciate to have the opportunity to not see this laud bar.
Comment 5 Cristian Adam 2018-04-23 13:45:20 UTC
I have found a partial workaround – namely changing the background color of the HTML Status Bar.

This can be done in Settings -> Configure KMail -> Appearance -> Colors. I have used "#fcfcfc" for all four "HTML Status Bar" entries.

Not the status bar is still eating valuable screen width, but at least is not an eye sore anymore.
Comment 6 bugzy 2018-04-23 13:57:16 UTC
I actually like the bar and its functionality. Not that my preference addresses the issue, but I am wondering if the toggle switch to turn off the bar at "Settings > Configure Kmail > Appearance > General > Show HTML Side Bar" has been removed. If not, simply turn it off.
Comment 7 Cristian Adam 2018-04-23 14:01:07 UTC
The setting ("Settings > Configure Kmail > Appearance > General > Show HTML Side Bar") has been removed in KMail 5.8.0 :(
Comment 8 Cristian Adam 2018-04-23 15:01:19 UTC
The commit which removed the setting: https://phabricator.kde.org/R94:1c55919a64491bd5598cf9d8616e77b037edbf87

In my opinion this needs to be reverted.
Comment 9 Piotr Keplicz 2018-04-23 21:22:53 UTC
I wish I could remove this status bar too. I find this information completely irrelevant and distracting.
Comment 10 Jani-Matti Hätinen 2018-04-24 03:30:38 UTC
This is horrible design, and the offered 'justification' for it is a sad, sad joke.

At least give us a configuration option we can add to kmail2rc.
Comment 11 Jani-Matti Hätinen 2018-04-24 03:48:32 UTC
If you're worried that new users won't be able to switch between HTML and non-HTML message views (a feature, which no one uses btw) make the HTML status bar visible by default and add a comment to the configuration page about the lost functionality if the bar is disabled. Simply forcing the bar on all users does absolutely nothing to promote said functionality.

99,5% of Kmail users are old users. Quit messing around with their settings. We've set it up the way we like it, and we know what we've done and why.
Comment 12 Jonathan Marten 2018-04-24 18:30:50 UTC
*** Bug 393473 has been marked as a duplicate of this bug. ***
Comment 13 bugzy 2018-04-25 02:10:11 UTC
Is there any way to re-open this issue. Whereas it is understandable that some kmail devs may want the html bar displayed by default in emails, there seems to be no real justification, or at least a satisfactory one, for removing the ability to change that default behavior. 

Note: I speak as one who uses and likes the html bar feature. I just don't think that it was reasonable to remove the ability to customize kmail, especially when there was no development cost that we know of(i.e. option that was already in place).
Comment 14 Jonathan Marten 2018-05-03 14:25:22 UTC
*** Bug 393595 has been marked as a duplicate of this bug. ***
Comment 15 Steeven Hudon 2018-05-05 04:44:06 UTC
I strongly agree with comments above > I think that this functionality might be required for some in their daily usage of the software.  However, I find it quite annoying visually and liked the ability we had in previous versions to remove this bar in the Settings. Please, put it back.  Thank you for your awesome job.  Kmail is a really great piece of software ! :)
Comment 16 pqz 2018-05-06 18:27:25 UTC
@Laurent Montel: a new user wouldn't know about any option in the setting dialog.
Your explanation makes no sense: should kmail disable any feature a new user doesn't know about.
This is a regression bug not a new feature: the setting use to be in the Settings dialog and now it's not. 
Why would this bug be closed as wont'f fix. What is not possible to fix or doesn't require a fix ?
Comment 17 PK 2018-05-07 07:18:01 UTC
I too can't understand why this happened. To me it is a strange choice. In my eyes there are a few (not much anymore) items to fix in kmail and this is NOT one of them. 
But still, you come a long end with the workaround from commend 5 that Christian Adams made: 

"I have found a partial workaround – namely changing the background color of the HTML Status Bar.
This can be done in Settings -> Configure KMail -> Appearance -> Colors. I have used "#fcfcfc" for all four "HTML Status Bar" entries."

You can make this ugly black disappear.
Comment 18 Pesho 2018-05-09 13:45:07 UTC
Please, return this option. I don't want HTML message status bar...
Comment 19 Richard Gladman 2018-05-23 21:08:07 UTC
Also affected by this bug. Please revert the removal of the setting (https://phabricator.kde.org/R94:1c55919a64491bd5598cf9d8616e77b037edbf87)
Comment 20 Ivo Smelhaus 2018-06-01 19:35:32 UTC
Just a very humble note to remember, that not everyone has not only the same point of view bat even the same abilities. E.g. my son is handicapped. He has impaired sight but additionally needs to have the things more simple to understand it. 
Kmail is actually the only mail client, which was possible to customize for his need. Yes, Kmail won in totally different field, than one could expected. It could be customized to be very simple, with big letters and big icons with best ratio between ability to see context and size of letters and icons. 
For me it always was a SW, which, if needed and if one is willing to spend many hours, is able to be customized in totally unique level. And this is absolutely different approach than the famous "we know perfectly what is the best for users, so we do that regardless the user want it or not" :-) . 
So the point of my note is, if it's really necessary to leave an area with unique position of the product. Btw. thanks my son's special needs, I discovered Linux years ago and we all switched to it as well. So back to Kmail. We can sure live with the html "something", but reading the discussion, I have a fear, that something has changed in the general approach and after next few changes like that, it becomes already unusable for us. And it would be very sad.
Comment 21 Coacher 2018-06-11 15:41:46 UTC
Please restore the ability to hide this ugliness. This bar is visually irritating.

Also rationale behind the change is wrong:
https://github.com/KDE/messagelib/commit/1c55919a64491bd5598cf9d8616e77b037edbf87

"We don't have other method as statusbarhtml for switching mode for the moment"

1. There's a shortcut to toggle HTML view.
2. There's a button that can be added to a toolbar to toggle HTML view.
Comment 22 Christoph Feck 2018-06-15 22:26:20 UTC
*** Bug 393473 has been marked as a duplicate of this bug. ***
Comment 23 Canoe 2018-08-17 20:22:32 UTC
Arbitrarily just changing this setting for users isn't the best experience. More so that i spent hours looking for ways to disable it as I usually do, only to find that option now disabled. While I appreciate all the work developers do on Kmail, - I think we're old enough to make our own decisions on what level of hand-holding we need in this area. There are enough markers and warnings as it is without another one staring us in the face.
Comment 24 PK 2018-08-18 06:04:00 UTC
Dear Canoe (of comment 23). I applied the workaround of Christian Adam in comment 5.
For the two foreground-items I choose the darker grey #7c7c7c and for the background items I choose the lighter grey #c0c0c0. It looks even cozy that way. But I am under the impression that we are protected against our selves and I don't like to be treated that way. To me that is un-kde-isch...
Comment 25 Robert-André Mauchin 2018-08-18 21:48:42 UTC
(In reply to Laurent Montel from comment #2)
> you can't to disable it as new user didn't know this feature.
> So now it's by default.
> Regards

There was no reason to remove this option for users. Put it back. We didn't come to KDE to be treated like we don't know better, we already have GNOME maintainer for that.
Comment 26 Störm Poorun 2018-08-19 21:02:31 UTC
Please use a discrete icon, or go back to the menu setting, or a toggle in the menu bar, or all three... but not a hideous line which should have stayed in the 1990s, which a user may not need and can't turn off, and which distracts Users and is thus bad for workflow (not to mention wasted time trying to figure out how to make it disappear!)
Comment 27 Sudhir Khanger 2018-08-28 03:54:37 UTC
This forced feature brings no benefit to me. I have already decided to use HTML and to load external resources by default. KMail should honor my decision.

It's distracting and ugly. Please bring back the ability to disable this feature.
Comment 28 Cristian Adam 2018-08-28 11:17:02 UTC
It has been four months already. How hard is for a KDE developer to revert a commit, review it, and merge it?

Is "Laurent Montel" the only developer who works on KMail?

If somebody does the revert today, it will take months (years?) until the distros get the fix.

This is crazy!
Comment 29 yuzyk 2018-09-03 21:35:11 UTC
KMail 5.8.3 now, I have to add my vote that this is annoying, even with Cristian's work-around. Please, Laurent! :)
Comment 30 yuzyk 2018-09-03 21:35:33 UTC
KMail 5.8.3 now, I have to add my vote that this is annoying, even with Cristian's work-around. Please, Laurent! :)
Comment 31 Pascal Patry 2018-09-05 14:20:15 UTC
This commit should definitely be reverted. Not only it removes a setting that we are used to set, it creates a flicker on the message pane. Whenever I switch folder, the bar disappears and it seems to appear again only once the content is displayed. So, the text in the email jump left then right every time I switch folder.

In order to have a working Kmail again, I've reverted the patch and rebuild the latest FC28 RPMs. The message lib is freely available here:
https://services.spectrumdt.com/RPMS/messagelib/

No bump in version were executed, so if you are running FC28, simply ensure that you have the latest version and then reinstall that RPM.
# dnf update messagelib
# rpm -vh --reinstall kf5-messagelib-18.04.3-1.fc28.x86_64.rpm
Comment 32 Attila 2018-09-23 12:35:44 UTC
Please return this option. What is the benefit of this HTML Message bar? I don't get it. It is annoying and it's all the time in the middle of the screen.
Comment 33 Christophe Giboudeaux 2018-09-27 08:29:02 UTC
As already mentioned earlier, this is intentional.
Comment 34 Erik Quaeghebeur 2018-09-27 08:59:24 UTC
(In reply to Christophe Giboudeaux from comment #33)
> As already mentioned earlier, this is intentional.
The fact that it is intentional does not address the issue of this bug report, which is that functionality that users really want has been removed.

My impression is that there is a push in the KMail development team to simplify the settings. That may be needed, but there are ways to avoid removing functionality at the same time. Namely, as was done for Bug 387931, the setting for this can for example be added to the Expert plugin.

From the commit message I understand that this is a transitional situation (“I will look at how I can change this feature in the future”). The response to this bug report has made it clear that during the transitional period it is preferable to still have this feature.

So please revert or add to the Expert plugin.

(FYI: I personally like and use the HTML bar.)
Comment 35 Sudhir Khanger 2018-09-27 14:09:46 UTC
Created attachment 115264 [details]
Alternate UI for the distracting and intrusive html bar

Is it necessary to keep it absolutely ugly and intrusive? Could we not come up with a UI that is less distracting to the users. Take for example, it can be shown at the top like the external resources message is shown which is less intrusive. Please see the screenshot attached.
Comment 36 Erik Quaeghebeur 2018-09-27 14:21:53 UTC
(In reply to Sudhir Khanger from comment #35)
> Is it necessary to keep it absolutely ugly and intrusive? Could we not come
> up with a UI that is less distracting to the users. Take for example, it can
> be shown at the top like the external resources message is shown which is
> less intrusive. Please see the screenshot attached.
This bug is about the option to hide the HTML bar, which has existed for a long time and is used and liked by many (and not by many others). This is not the place to discuss alternative UI proposals. Please keep on topic.
Comment 37 Peter Humphrey 2018-09-28 08:52:50 UTC
(In reply to Christophe Giboudeaux from comment #33)
> As already mentioned earlier, this is intentional.

Being intentional doesn't mean it's a good idea. It isn't, as the flood of comments here shows.

What other development team ignores its users?
Comment 38 Störm Poorun 2018-09-28 09:18:56 UTC
Open source...

Part of the KDE family...

Not: 'I'm the maintainer, therefore we can ignore all Users without any rational reason'.

It raises the question, who gets to decide here? 

It would be a shame to have to fork this software over one ridiculous and irrational design choice, but if a decision like this rests in just one pair of hands and no-one can have any influence, than fair enough - I guess that's the end result, it also explains so many other opensource software splits in the past.

You can have usability AND customisation, by intelligent defaults, combined with  advanced settings with certain users.

However, this decision renders Kmail neither usable nor customisable.

No other software makes the casual user have to face an ugly distraction on every email, with no way of turning it off.

Advanced setting removed. Because the Users can't be trusted to know their own needs and take their own risks?

And no better way of presenting the option than a block line across every email. Ouch.
Comment 39 avlas 2018-09-28 12:05:31 UTC
Yes, it doesn't make any sense (this is just my opinion -- a user that agrees on 99.9% of KDE dev decisions, but not this one).

This reminds me plasma cashew, btw...
Comment 40 Brent 2018-09-28 12:20:58 UTC
+1 for removing HTML-view feedback (aka the bar, vignet). I think users understand their own preferences without it.
Comment 41 pqz 2018-09-29 00:03:25 UTC
(In reply to Erik Quaeghebeur from comment #36)
> (In reply to Sudhir Khanger from comment #35)
> > Is it necessary to keep it absolutely ugly and intrusive? Could we not come
> > up with a UI that is less distracting to the users. Take for example, it can
> > be shown at the top like the external resources message is shown which is
> > less intrusive. Please see the screenshot attached.
> This bug is about the option to hide the HTML bar, which has existed for a
> long time and is used and liked by many (and not by many others). This is
> not the place to discuss alternative UI proposals. Please keep on topic.



And where is the right place to discuss alternative UI proposals ?
There was no discussion when the feature was removed.
Comment 42 Erik Quaeghebeur 2018-09-29 11:32:28 UTC
(In reply to pqz from comment #41)
> And where is the right place to discuss alternative UI proposals ?
Another bug report (as feature request), kdepim-devel mailing list, KDE forums.

> There was no discussion when the feature was removed.
Not with users, indeed, and that is one of the reasons this bug report is so ‘popular’.
Comment 43 pqz 2018-09-29 13:08:30 UTC
(In reply to Christophe Giboudeaux from comment #33)
> As already mentioned earlier, this is intentional.


Wouldn't be more simple to change the type of this ticket (to feature request) instead of opening another one ?

Closing with the explanation that was given seem a bit rude to me.
Comment 44 pqz 2018-09-29 13:08:58 UTC
(In reply to Christophe Giboudeaux from comment #33)
> As already mentioned earlier, this is intentional.


Wouldn't be more simple to change the type of this ticket (to feature request) instead of opening another one ?

Closing with the explanation that was given seem a bit rude to me.
Comment 45 Christophe Giboudeaux 2018-09-30 15:40:00 UTC
*** Bug 393595 has been marked as a duplicate of this bug. ***
Comment 46 pqz 2018-09-30 16:13:31 UTC
(In reply to Erik Quaeghebeur from comment #42)
> Another bug report (as feature request), kdepim-devel mailing list, KDE

Here it is: bug 399245 as a feature request
Comment 47 avlas 2018-10-29 21:21:33 UTC
(In reply to Cristian Adam from comment #5)
> I have found a partial workaround – namely changing the background color of
> the HTML Status Bar.
> 
> This can be done in Settings -> Configure KMail -> Appearance -> Colors. I
> have used "#fcfcfc" for all four "HTML Status Bar" entries.
> 
> Not the status bar is still eating valuable screen width, but at least is
> not an eye sore anymore.

This workaround only works for Kmail launched as a single application. It has not effect if Kmail is embedded in Kontact.

Not that I wanted to remove it completely but I wanted a more integrated background in white with nice text in soft blue (breeze like). But no way to do this :(
Comment 48 avlas 2019-01-24 23:09:09 UTC
(In reply to avlas from comment #47)
> (In reply to Cristian Adam from comment #5)
> > I have found a partial workaround – namely changing the background color of
> > the HTML Status Bar.
> > 
> > This can be done in Settings -> Configure KMail -> Appearance -> Colors. I
> > have used "#fcfcfc" for all four "HTML Status Bar" entries.
> > 
> > Not the status bar is still eating valuable screen width, but at least is
> > not an eye sore anymore.
> 
> This workaround only works for Kmail launched as a single application. It
> has not effect if Kmail is embedded in Kontact.
> 
> Not that I wanted to remove it completely but I wanted a more integrated
> background in white with nice text in soft blue (breeze like). But no way to
> do this :(

There is actually a way to do this, but it's far from obvious, as one needs to apply this in kmail settings and then copy that section to kontact settings manually... 

No need to say that this should be applied directly withouth having to:

1. Open kmail as a standalone application
2. Change the settings
3. Open kmailrc and copy the relevant section
4. Edit kontactrc by pasting that settings section
Comment 49 Sudhir Khanger 2019-01-25 05:21:27 UTC
@avlas thanks for that info. By any chance do you have the code that is relevant for removing this egregious UI.
Comment 50 avlas 2019-01-25 05:36:20 UTC
(In reply to Sudhir Khanger from comment #49)
> @avlas thanks for that info. By any chance do you have the code that is
> relevant for removing this egregious UI.

Sorry, perhaps I was not clear enough. These config sections are not for disabling the html status bar, but for changing its appearance.

These are my settings in the Reader section of kontactrc and kmail2rc:

ColorbarBackgroundHTML=250,251,252
ColorbarBackgroundPlain=250,251,252
ColorbarForegroundHTML=0,116,185
ColorbarForegroundPlain=250,251,252

I configured it so that the background of the html status bar always matches the window background color (according to the color scheme you use), and for the text color, I set it to blue when HTML is active, and virtually invisible otherwise (by matching the color of the background in plain text emails).
Comment 51 Sudhir Khanger 2019-01-25 10:42:42 UTC
Created attachment 117651 [details]
html white bar

Even if you set the colors to either white or grayish you will end up with same bad UI behavior.

@avlas Where do I put ColorbarBackground code? Under some heading like [Reader] or just at the bottom.

[Reader]
CloseToQuotaColor=218,68,83
ColorbarBackgroundHTML=255,255,255
ColorbarBackgroundPlain=255,255,255
ColorbarForegroundHTML=255,255,255
ColorbarForegroundPlain=255,255,255
LinkColor=41,128,185
QuotedText1=32,145,80
QuotedText2=26,116,64
QuotedText3=19,87,48
ScamDetectionEnabled=false
attachment-strategy=inlined
defaultColors=false
header-plugin-style-name=brief
htmlLoadExternal=true
htmlMail=true
showColorBar=false
Comment 52 avlas 2019-01-25 11:33:03 UTC
(In reply to Sudhir Khanger from comment #51)
> Created attachment 117651 [details]
> html white bar
> 
> Even if you set the colors to either white or grayish you will end up with
> same bad UI behavior.
> 
> @avlas Where do I put ColorbarBackground code? Under some heading like
> [Reader] or just at the bottom.
> 
> [Reader]
> CloseToQuotaColor=218,68,83
> ColorbarBackgroundHTML=255,255,255
> ColorbarBackgroundPlain=255,255,255
> ColorbarForegroundHTML=255,255,255
> ColorbarForegroundPlain=255,255,255
> LinkColor=41,128,185
> QuotedText1=32,145,80
> QuotedText2=26,116,64
> QuotedText3=19,87,48
> ScamDetectionEnabled=false
> attachment-strategy=inlined
> defaultColors=false
> header-plugin-style-name=brief
> htmlLoadExternal=true
> htmlMail=true
> showColorBar=false

Under [Reader]
Comment 53 Konrad Rzepecki 2019-02-05 10:20:51 UTC
I just begin to test KDE5/Plasma, and I definitely want to have option to remove this crappy bar!!!

I have problem with enable message structure which you also want to remove. In bug 387931 you restore that functionality in expert plugin. Option to hide this THING can be also put there - since message structure also can be used to change html/text parts.
Comment 54 PK 2019-02-06 06:23:12 UTC
What starts to puzzle me about this whole discussion is that no one ever took the trouble of explaining why this bar had to be fixed. Why so many faithful users had to be "kicked against the sore leg" as we say in my country.
It seems to me that there must be a really simple and good explanation to take a measure that harsh that also ruins the looks of your application.
What is this reason? Please explain.
Comment 55 Christoph Feck 2019-02-22 17:59:52 UTC
It is a security reason. You could receive an HTML mail that looks like a plain text mail, and with HTML you have the ability to embed malicious links everywhere. If you have no way to see that the message is actually an HTML message, i.e. _outside_ the message viewer, you could click those links without being aware that they link to sites that you don't see in the text.

I agree, though, that there could be other possibilities to inform the user of HTML mails, e.g. via statusbar or toolbar icons. But if they are too non-obvious, you could miss them. In other words, if the security bar is in your face, it actually works as intended.

Also, the message viewer doesn't know about other UI elements. If you find a different way that doesn't compromise security, please let us know. Patches to https://phabricator.kde.org/differential/diff/create/
Comment 56 Nate Graham 2019-02-22 18:14:56 UTC
I think most people don't object to real security. What people object to here is the following:

- It's not clear how this thing actually generates any security. HTML emails are not commonly understood by the average user to be potentially insecure, so warning them than an HTML email is in fact an HTML email is not perceived as a warning of potential danger but rather as a pointless annoyance.

- It can't be disabled at the user's preference. Risk is an everyday part of life, but there is no way for a knowledgeable or confident user to knowingly accept the risk of HTML emails in KMail they way they can knowingly accept the risk of driving a car, participating in sports, etc. It feels insulting when the software says, "you can't handle this risk". Imagine how infuriating it would be if your car told you "Warning! Driving a car is dangerous! Please drive safely!" every time you turned it on.

- It's ugly. There are many ways to communicate this information in ways that are not so visually objectionable. Thunderbird uses a horizontal bar with a yellow background that looks much better, for example.
Comment 57 Martin Steigerwald 2019-02-22 20:06:01 UTC
Nate, I agree that the current solution looks quite out of place.

There is the writing "no HTML message" black on white when the message just has no HTML part. There is the writing "clear text message" black on white, when it has one but the cleartext part is shown. There is the writing "HTML message" white on black when the HTML part is shown. And then there is a bug when switching from HTML part back to clear text part, it still display "HTML message" white on black.

So first the choice of colors IMHO is just ugly. The colors do not blend well with Breeze Dark theme. The white on black "HTML message" bar totally looks out of place. Second it has three states, while for the user only one information is important: Is what is currently viewed HTML or is it not. With the option that when both clear text and HTML are available, that HTML status bar allows to toggle.

In addition in my KMail configuration for security reason I do not even let it render HTML without my prior confirmation. Thus I have a box with red frame at the top of the mail with "Note: This is an HTML message. For security reasons, only the raw HTML code is shown. […]" giving me the option to enable HTML rendering in case I trust the sender. In case KMail is configured like this the vertical bar is completely superfluous. I believe with good user interface design it might be possible to merge both this box and the HTML status bar into one and make it less intrusive.

Laurent, Christoph, I kindly ask you to reconsider and at ask for input from VDG team. And if on it, it might be good when VDG people look through the rest of the application as well. Thus I'd reopen the bug and set usability tag.
Comment 58 Peter Humphrey 2019-02-23 09:06:18 UTC
(In reply to Christoph Feck from comment #55)
> It is a security reason. You could receive an HTML mail that looks like a
> plain text mail, and with HTML you have the ability to embed malicious links
> everywhere. If you have no way to see that the message is actually an HTML
> message, i.e. _outside_ the message viewer, you could click those links
> without being aware that they link to sites that you don't see in the text.
This is completely spurious. If you click on a link, you know it's a link. If it's a link it must be in HTML. You don't need an ugly great splodge to tell you it's HTML.

If you think there are people who can't see this, let them keep the warning. The rest of us, who've used the Internet for more than five minutes, should be allowed to switch the splodge off, as we always used to be.
Comment 59 Martin Steigerwald 2019-02-23 10:43:51 UTC
(In reply to Peter Humphrey from comment #58)
> (In reply to Christoph Feck from comment #55)
> > It is a security reason. You could receive an HTML mail that looks like a
> > plain text mail, and with HTML you have the ability to embed malicious links
> > everywhere. If you have no way to see that the message is actually an HTML
> > message, i.e. _outside_ the message viewer, you could click those links
> > without being aware that they link to sites that you don't see in the text.
> This is completely spurious. If you click on a link, you know it's a link.
> If it's a link it must be in HTML. You don't need an ugly great splodge to
> tell you it's HTML.
> 
> If you think there are people who can't see this, let them keep the warning.
> The rest of us, who've used the Internet for more than five minutes, should
> be allowed to switch the splodge off, as we always used to be.

Peter, KMail has clickable links also in plain text view. In HTML however the link can go to an entirely different location than what the user gets to see, while in plain text it cannot. Thus there is a valid security concern.
Comment 60 Peter Humphrey 2019-02-23 16:22:14 UTC
(In reply to Martin Steigerwald from comment #59)

> KMail has clickable links also in plain text view. In HTML however
> the link can go to an entirely different location than what the user gets to
> see, while in plain text it cannot. Thus there is a valid security concern.

Ah, well in that case, maybe you've just shown the route to a solution: make sure that both views show the same, real value of the link.

I can see there may be complications in doing that (different display engines being used) but this seems to be where the insecurity comes from - not from the user, who's unlikely to understand that the black bar is trying to warn him of the distinction you've drawn: what it says is nothing like what it seems to mean. I didn't see it anyway, in spite of having been using the Internet for a bit longer than five minutes.  :)
Comment 61 PK 2019-05-20 10:43:06 UTC
Is anything happening with this bug? There are many reactions. E.g. a father with a son who is visually handicapped and also the very respected Nate Graham took the time to explain why this html-bar is a mistake - and he explained very clear! I can only imagine that if he enters this discussion something must be very wrong! When are you reverting this change? Kmail is becoming a very good application. Stop messing it up!
Comment 62 Christophe Giboudeaux 2019-06-16 15:26:09 UTC
*** Bug 408727 has been marked as a duplicate of this bug. ***
Comment 63 mail 2019-06-29 20:52:02 UTC
Is there maybe a fork of kmail that doesn't pander to the pathetic?

Removing settings is patronising to new users and annoying to everyone else.  As to the "security" justification, that is the user's responsibility if they choose to disable the bar and then blindly click on emails, not yours. 

At the very least make it a bit less 'in your face' - other email clients seem to manage without a big ugly vertical text thing there.
Comment 64 whatifgodwasoneofus 2019-06-30 13:15:10 UTC
(In reply to mail from comment #63)
> Is there maybe a fork of kmail that doesn't pander to the pathetic?

Maybe that would be a solution.
Comment 65 Marcin Juszkiewicz 2021-07-21 15:40:24 UTC
Bugs like this are one of reasons I stopped reporting bugs against KDE.
Comment 66 Niels 2021-11-09 11:45:09 UTC
Surprised to find that we cannot disable the bar (anymore), but are still allowed to obfuscate it by changing its colors. This makes little sense, unless the goal is to have kmail's appearance be less attractive and inconsistent.
Comment 67 Peter Humphrey 2021-11-09 16:46:11 UTC
(In reply to Niels from comment #66)
> Surprised to find that we cannot disable the bar (anymore), but are still
> allowed to obfuscate it by changing its colors. This makes little sense,
> unless the goal is to have kmail's appearance be less attractive and
> inconsistent.

Maintainer knows best. Well, he thinks we shouldn't be allowed to assess our own risks. Arrogance personified. Just shrug and move on...
Comment 68 Lukas Ba. 2022-02-27 00:17:49 UTC
> It is a security reason. You could receive an HTML mail that looks like a plain text mail, and with HTML you have the ability to embed malicious links everywhere. If you have no way to see that the message is actually an HTML message, i.e. _outside_ the message viewer, you could click those links without being aware that they link to sites that you don't see in the text.

I just assume that every message is an HTML message. Most of the time i am right.

I changed all the colors to black. It's what i call security by obscurity ;-)

I wonder when K9Mail authors are going to remove the ability to open links in your browser of choice and only allow wget piped into less because it's obviously more secure than GUI browsers.