GNOME Bugzilla – Bug 752511
"View Source" (Ctrl+U) is very slow on huge messages; freezes evolution
Last modified: 2015-07-22 15:45:08 UTC
Steps to reproduce: 1. open evolution 2. view any message with big attachments, e.g. 3MiB of size 3. view source of this message (using Ctrl+U) What happens: evolution freezes for some time, it seems like big mails take very long to render in evolution. After that it continues to work, but with some lags (until message source window is closed). What is expected to happen: evolution should not freeze. Additional info: gedit is loading the same file much faster and with only slight lag/freeze (~1s compared to 30s for a sample 3MiB file). Would it not be easier to just display a non-editable GtkSourceView or GtkTextView? Or directly use gedit (or any other default text editor) as external application?
Thanks for a bug report. Showing the message source is the same as showing the message itself, or a message with the same large text body. I mean, it is shown in a very similar way. Giving a backtrace of the evolution when it is frozen will show what it does. If I'm not mistaken, then it is inside a webkit rendering code, like bug #743926. You can get a backtrace with a command like this: $ gdb --batch --ex "t a a bt" -pid=`pidof evolution` &>bt.txt Please check the bt.txt for any private information, like passwords, email address, server addresses,... I usually search for "pass" at least (quotes for clarity only).
Created attachment 307867 [details] The backtrace as requested in comment #1 Here is the backtrace. I didn't change anything, found no private information in it.
Created attachment 307868 [details] Another backtrace (see comment), created the same way as before Actually I fined this bug because of another reason: I recently stumbled upon a message with broken MIME. The attachment (PDF file) had Content-Type set to text/html, evolution told me this was an HTML attachment. I was curious so I expanded it, then evolution froze for a while until it had the PDF file loaded. I don't know whether this is the same issue, but I attached the backtrace for this too. I know that this is not evolutions fault and I don't know whether evolution should be bug-compatible (bug-proof) in this rare case. I don't even know whether both issues are the same. If not, tell me or file a new bug report. The header of this attachment looks like this: --------------080509020902040403050200 Content-Type: text/html; name="filename.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="filename.pdf"
Thanks for the update. The backtrace matches the one at bug #705705, while there can be found more when searching for "updateStyleIfNeeded" symbol. I'll use that bug for this one. The text/html for a .pdf file is really something the sending client made wrong, as you said. The backtrace is different, though the issue quite the same - the message strcture is quite complex, thus it takes webkit a bit of time to process it. *** This bug has been marked as a duplicate of bug 705705 ***