Due to missing config.h the ENABLE_SMIME was not declared, thus the type
for the S/MIME parser was not registered, neither used, which showed
S/MIME signed or encrypted messages as attachments, instead of deciphering
their content.
The application/postscript mime type had been handled by the text-hightlight
module, but thinking of it, it doesn't make much sense, because most users
would prefer to see the content rather in a postscript viewer, than
the source of the postscript file, thus this change removes the mime type
from the text-hightlight module. There had been also issues about thinking
that certain parts had been handled, while they did not, which this change
fixes as well.
The issue had been reported downstream at:
https://bugzilla.redhat.com/show_bug.cgi?id=1187327
I received one message and on its end there was the paragraph element
left opened:
</p><p></body></html>
When we appended the credentials after it:
</p><p></body></html><span class="-x-evo-to-body" data-credits><pre>credits</pre></span>
Now WebKit tried to do its best to parse, fix and load the content correctly that
resulted in:
<p><span class="-x-evo-to-body" data-credits></span></p><pre>credits</pre></body></html>
Clearly, we will fail when moving the credits to right place as we are
expecting the the credits are inner part of the span. So set the
credentials into the data-credits attribute (as there it will be
resistant against this behavior) and rework the part that's handling it.
This makes evolution depend on theme-defined named colors, namely:
theme_bg_color
theme_base_color
theme_fg_color
theme_text_color
theme_selected_bg_color
theme_selected_fg_color
theme_unfocused_selected_bg_color
theme_unfocused_selected_fg_color
If it's not defined, then a fallback color is used, in the worse case
one of the fallbacks defined in evolution itself.
If there was a known formatter for the attachment's mime type, the attachment
content was shown inline, without the attachment button, instead of it being
shown collapsed and with the corresponding button. All that caused by a variable
overwrite and a related memory leak.
GFilterOutputStream, from which CamelFilterOutputStream is derived,
defaults to closing its base stream when the instance is finalized.
That makes sense in the general case, but CamelFilterOutputStreams are
usually temporary wrappers on a more permanent base stream, so we need
to remember to override the default "close-base-stream" property value.
I was tempted to just make CamelFilterOutputStream override the default
automatically, but I decided against it because my long term plan is to
drop CamelFilterOutputStream for GConverterOutputStream which also does
not override the "close-base-stream" default. The closer the semantics
of the two classes match, the easier porting will be in the future.
Win32 headers have a #define for 'interface', which breaks the build
when this word is used in the code, thus replace it to 'iface',
the same way as GLib or GTK+ code use to have it. (See bug #722068.)
Any GtkWidget creation or manipulation should be done exclusively
from the main/UI thread, thus make sure it is done that way.
Of course, evolution can freeze for a little time (depends on the message
size), until its formatting is done. It's unnoticeable with usual messages.
Drop our explicit gstreamer requirement and merge audio support directly
into libevolution-mail-formatter. We now use the HTML5 <audio> tag and
let WebKit show much nicer playback controls, with volume and seeking.
This makes the code free of Coverity scan issues.
It is sometimes quite pedantic and expects/suggests some
coding habits, thus certain changes may look weird, but for a good
thing, I hope. The code is also tagged with Coverity scan
suppressions, to keep the code as is and hide the warning too.
Also note that Coverity treats g_return_if_fail(), g_assert() and
similar macros as unreliable, and it's true these can be disabled
during the compile time, thus it brings in other set of 'weird'
changes.
This is only a partial solution for the test case the bug report.
The message/news part of the test case is also Base64-encoded, but
Evolution (or Camel) is not decoding it properly. Still digging.
The "signature bar" overrides background color, thus it should
override also text color, to make sure the text will be always
readable. This could break with dark theme, which uses light
text color.
When we were collecting the elements for adding the onclick event
listeners, we were using the webkit_dom_document_get_element_by_id
method, but when email had multiple TO, CC or BCC headers it was
returning just the first elements with given id. To fix this we moved
to webkit_dom_*_query_selector methods that give us more powerfull
element extraction from document.
When toggling the visibility of header row, we are now operating just
in the row that contains the clicked element.
This patch also remove the suffixes from all __evo-moreaddr ids.
Avoid redrawing (thus loosing the selection and scroll position) of
preview window on style change by defining the colors through CSS styles.
On style change we just update the CSS color definitions and preview will
update itself without redraw.
Commit 514736f27e in 3.9.5 broke inline
PGP encrypted messages, because the parser was treating the encrypted
message content as an attachment even though the content type is just
text/plain. This ensures the message content is treated correctly.
Simo Sorce sent me an interesting case where the MIME type of the
message itself was image/gif, but the image was not being shown.
If the EMailPart representing the message body is marked as an
attachment, wrap it as such so it gets added to the attachment
bar but also set the "force_inline" flag since it doesn't make
sense to collapse the message body if we can render it. */
