Red Hat Bugzilla – Bug 949610
Don't block UI while downloading message attachment
Last modified: 2014-01-02 05:45:01 EST
Created attachment 732721 [details] full backtrace Description of problem: When the message body or attachment is being downloaded, the evo UI is frozen. Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. have a large message (message with large attachment) in your inbox 2. make sure that the message/attachment in question is not cached 3. click the message in msglist, if the message loads, click attachment Actual results: evo UI blocks for the time of the download without any visual cue that it is actually well and alive Expected results: evo UI keeps responding while the transfert takes place in the background Additional info: backtrace taken during download of MB-sized attachment over GPRS/EDGE connection (~ 25 kB/s - download time in order of minutes) - note that both transfer and UI takes place in Thread 1. Full backtrace is attached as a file Thread 1 (Thread 0x7f44c483a980 (LWP 28990)): #0 0x00000036aa2df253 in __poll (fds=<value optimized out>, nfds=<value optimized out>, timeout=<value optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87 #1 0x0000003b23c26579 in ?? () from /lib64/libnspr4.so #2 0x0000003b23c2746d in ?? () from /lib64/libnspr4.so #3 0x0000003b2441b1ed in ssl_DefRecv (ss=<value optimized out>, buf=<value optimized out>, len=1408, flags=<value optimized out>) at ssldef.c:62 #4 0x0000003b24416480 in ssl3_GatherData (ss=0x6575ce0, flags=0) at ssl3gthr.c:59 #5 ssl3_GatherCompleteHandshake (ss=0x6575ce0, flags=0) at ssl3gthr.c:318 #6 0x0000003b244169ea in ssl3_GatherAppDataRecord (ss=0x6575ce0, flags=0) at ssl3gthr.c:404 #7 0x0000003b2442050a in DoRecv (ss=0x6575ce0, buf=0x7f44ad00554c '\023' <repeats 200 times>..., len=12137297, flags=0) at sslsecur.c:535 #8 ssl_SecureRecv (ss=0x6575ce0, buf=0x7f44ad00554c '\023' <repeats 200 times>..., len=12137297, flags=0) at sslsecur.c:1144 #9 0x0000003b244247d2 in ssl_Read (fd=<value optimized out>, buf=0x7f44ad00554c, len=12137297) at sslsock.c:2112 #10 0x0000003b2684c152 in stream_read (stream=<value optimized out>, buffer=0x7f44ad00554c '\023' <repeats 200 times>..., n=12137297) at camel-tcp-stream-ssl.c:347 #11 0x0000003b258472a6 in stream_read (stream=<value optimized out>, buffer= 0x7f44aceeb011 "UEsDBBQAAgAIAOhucEKOkKdcAh4QAFoWEAAKAAAASU1HMDI2LmpwZ5xUeTyUaxt+39mM4ZD1KERZ\r\nxgmnGUz2PUSklH0pe7ZK1sqk7HKSGVmyK0xiyr6GT2Rp4SBLqI79cBJCdvO9Y6vvd84f3/fdv9/9\r\n3tfzvNdzP9f1Ps/vpfXRhn5J0/J3cQIAAwPgCAAAaAAN"..., n=12137297) at camel-stream-buffer.c:247 #12 0x00007f44b75fe281 in imap_read_untagged (store=0x1369620, response=0x7fffa437ea78, ex=0x0) at camel-imap-command.c:489 #13 camel_imap_command_response (store=0x1369620, response=0x7fffa437ea78, ex=0x0) at camel-imap-command.c:342 #14 0x00007f44b75fe71c in imap_read_response (store=0x1369620, ex=0x0) at camel-imap-command.c:396 #15 0x00007f44b75ff045 in camel_imap_command (store=0x1369620, folder=0x16ec980, ex=0x0, fmt=<value optimized out>) at camel-imap-command.c:116 #16 0x00007f44b75ffd89 in camel_imap_folder_fetch_data (imap_folder=0x16ec980, uid=0x62bc7e0 "16394", section_text=<value optimized out>, cache_only=0, ex=0x0) at camel-imap-folder.c:3827 #17 0x00007f44b7614a30 in write_to_stream (data_wrapper=0x5c40ec0, stream=0x64962d0) at camel-imap-wrapper.c:139 ---Type <return> to continue, or q <return> to quit--- #18 0x0000003b2581f450 in decode_to_stream (data_wrapper=0x5c40ec0, stream=<value optimized out>) at camel-data-wrapper.c:210 #19 0x0000003b25833a1b in camel_mime_part_get_content_size (mime_part=<value optimized out>) at camel-mime-part.c:1125 #20 0x0000003b26432a08 in attachment_load_from_mime_part (attachment=<value optimized out>, callback=<value optimized out>, user_data=<value optimized out>) at e-attachment.c:1785 #21 e_attachment_load_async (attachment=<value optimized out>, callback=<value optimized out>, user_data=<value optimized out>) at e-attachment.c:1853 #22 0x00007f44bc3fbcb3 in efhd_attachment_button (efh=0x167b0c0 [EMFormatHTMLDisplay], eb=0x5a16e00 [GtkHTMLEmbedded], pobject=<value optimized out>) at em-format-html-display.c:1419 #23 0x00007f44bc3fc9fe in efh_object_requested (html=<value optimized out>, eb=0x5a16e00 [GtkHTMLEmbedded], efh=0x167b0c0 [EMFormatHTMLDisplay]) at em-format-html.c:637 #24 0x0000003831677488 in html_g_cclosure_marshal_BOOLEAN__OBJECT (closure=0x16a6ce0, return_value=0x7fffa437f050, n_param_values=<value optimized out>, param_values=0x37f6430, invocation_hint=<value optimized out>, marshal_data=<value optimized out>) at htmlmarshal.c:81 #25 0x00000036ac60bb3e in IA__g_closure_invoke (closure=0x16a6ce0, return_value=0x7fffa437f050, n_param_values=2, param_values=0x37f6430, invocation_hint=0x7fffa437eec0) at gclosure.c:767 #26 0x00000036ac620e23 in signal_emit_unlocked_R (node=<value optimized out>, detail=0, instance=0x14f1660, emission_return=0x7fffa437f050, instance_and_params=0x37f6430) at gsignal.c:3247 #27 0x00000036ac621f4a in IA__g_signal_emit_valist (instance=<value optimized out>, signal_id=<value optimized out>, detail=<value optimized out>, var_args=0x7fffa437f0b0) at gsignal.c:2990 #28 0x00000036ac6225f3 in IA__g_signal_emit (instance=<value optimized out>, signal_id=<value optimized out>, detail=<value optimized out>) at gsignal.c:3037 #29 0x0000003831634e4e in html_engine_object_requested_cb (engine=<value optimized out>, eb=0x5a16e00 [GtkHTMLEmbedded], data=0x14f1660) at gtkhtml.c:550
clickable upstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=600860
Created attachment 733191 [details] evolution-2.28.3-async-load.patch Backport of the upstream bug patch. It works as expected, according to my test.
I forgot rhel build where I reproduced the behaviour so here it is: evolution-2.28.3-30.el6.x86_64
I updated a patch for asynchronous attachment load, because each view of a message with an image attachment caused pair of runtime warnings: > GLib-GIO-CRITICAL **: g_file_info_set_size: assertion `G_IS_FILE_INFO (info)' > failed > GLib-GIO-CRITICAL **: g_file_info_get_icon: assertion `G_IS_FILE_INFO (info)' > failed due to asynchronous load, when the file_info held on EAttachment was not set yet. It's part of evolution-2.32.3-15.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2013-1540.html