GNOME Bugzilla – Bug 606239
Better indication of signed and/or encrypted received email
Last modified: 2015-04-20 15:00:56 UTC
this report has been filed here: https://bugs.edge.launchpad.net/ubuntu/+source/evolution/+bug/495936 "Currently in Evolution, when a received email is signed and/or encrypted but it is longer than the available space on the screen, there is no indication at all on the screen that the email is signed and/or encrypted. The green bar which indicates this gets pushed down off the screen and the only way to tell that the email is signed and/or encrypted is to scroll all the way down. This is suboptimal. I propose that Evolution indicates that an email is signed and/or encrypted in such a way that it is always visible on the screen, no matter how long the email or the position of the scroll bar, using one or more of the following methods: * Fix the position of the green bar so that it doesn't scroll with the message but is always visible underneath the scrolled area. * Fix the position of the email headers area and add an icon there to indicate signed and/or encrypted * Add an icon to the message list, or a decoration to the icon already displayed there, indicating that a message is signed and/or encrypted (or possibly only encrypted, since the message structure is needed to determine whether it is signed)" Thanks,
Created attachment 288058 [details] [review] add Securtiy Header and color frame In my opinion making headers or secure-button always visible would take up too much space, instead I suggest the following: - always add Security-Header (already in use for printing) - color the frame around the body (I think KMail is doing too) using secure-button colors TODO: - test richtext formatter, evo sends out html or plain only - test formatter-plain -- highlight-text-module and formatter-plain both register for text/plain -- e-mail-request iterates over parts, looking up formatters by mime-type -- text/plain is first processed by highlight, which will create <iframe> RAW -- when the <iframe> is rendered formatter-plain is called in RAW mode -- the question is how can I test the <iframe> created in formatter-plain? is this code ever executed?
Created attachment 288059 [details] Example
Review of attachment 288058 [details] [review]: Thanks for the patch. I tested it and at least the case where the key is missing (needs_key style) sets border which has (almost) the same color as the other background, which makes the message body look weird, like without any frame. I would also prefer to show a quick validity button at the top-right place, beside the headers, just like the Face header is shown, thus it'll be both at the top and at the button. Such button should be really just the button and nothing more, the same as at the bottom, with a tooltip describing why it's there (basically the text which is currently on the right from the button at the bottom part). Otherwise the frame looks nice with green/red/yellow color when signed/encrypted. > TODO: Please remove the TODO notes from the code. > - test richtext formatter, evo sends out html or plain only That is tricky, those are usually sent by Outlook-like clients. I do not think I have any such mail, neither signed/encrypted. > - test formatter-plain > -- highlight-text-module and formatter-plain both register for text/plain this is correct, the highlight-text module can override the plain formatter (you can add your own formatter on top of those provided by evolution). To have plain formatter in action simply remove the text-highlight module from your $PREFIX/evolution/modules/. ::: em-format/e-mail-part-utils.c @@ +59,3 @@ + */ +const gchar* +e_mail_part_get_frame_style (EMailPart *part) a) coding style: space before '*' at 'gchar*" b) name the function like e_mail_part_get_frame_security_style() and let it return and empty string instead of "-e-mail-formatter-frame-security-none", which will make it use the default frame style. @@ +80,3 @@ + } else if (frame_style == NULL && + pair->validity->sign.status == CAMEL_CIPHER_VALIDITY_SIGN_NEED_PUBLIC_KEY) { + frame_style = "-e-mail-formatter-frame-security-need_key"; use a consistent naming, aka not "need_key", byt "need-key" (underscore versus dash). ::: mail/e-mail-display.c @@ +849,3 @@ } else if (g_strstr_len (color_name, -1, "frame")) { style = g_strconcat ( + "border-color: ", color_value, NULL); That '!important' was required for something, I think when the GtkStyleContext changes.
I'll look into the issues, in the meantime I'd like to respond to the comments concerning "!important" and "-e-mail-formatter-frame-security-none" I assume that "!important" was chosen to make the email body independent of the theme, effectively disabling any "CSS logic" [1]. I'd like to enable CSS, this is where "-e-mail-formatter-frame-security-none" comes into play. It provides the option to make the mail body border look different from other borders. This is not used at the moment but everything is prepared, you just have to define "-e-mail-formatter-frame-security-none". If you think this will not work or might break something, could you please provide an example (test case). I can then try to fix that use case or fall back to use "!important" instead. [1] http://css-tricks.com/when-using-important-is-the-right-choice/
Tomas, could you check and answer the comment #4, please?
Created attachment 295372 [details] [review] security frame RC1 - removed TODOs - checked code concerning "-e-mail-formatter-frame-security-none": this css class is required to get the 1px border around none encrypted mail bodies. - need-key and unknown are now displayed using the same frame color
Created attachment 295373 [details] [review] Security button in header I suggest not to add a button to the header. I find it rather hard to control the dimensions of the button (especially if headers are collapsed) due to the way <object> is handled by webkit.
Thanks for the update. The first patch looks fine, I committed it to sources. I also tried the second patch and I agree it'll be better not to do it, for the reason you gave, then also for the reason that there might be multiple buttons for attached messages and because the patch introduces runtime warnings: > (evolution:12830): GLib-GObject-WARNING **: invalid cast from > 'WebKitDOMHTMLIFrameElement' to 'WebKitDOMHTMLObjectElement' > > ** (evolution:12830): CRITICAL **: void > webkit_dom_html_object_element_set_height(WebKitDOMHTMLObjectElement*, const > gchar*): assertion 'WEBKIT_DOM_IS_HTML_OBJECT_ELEMENT(self)' failed as we'll skip the patch there nothing left to be done for this bug report. Created commit 5130f21 in evo master (3.13.90+) [1] [1] https://git.gnome.org/browse/evolution/commit/?id=5130f21
A 4-pixel wide border looked fine for single emails, but once the message was part of a conversation, with quoted replies, the wider border was confusing, too close to the quotation line. The below change moves the wider border to the opposite side. Created commit 2122c65 in evo master (3.13.90+)
*** Bug 700287 has been marked as a duplicate of this bug. ***