Also hangs with Claws 3.7.6 on Debian Squeeze (6.0.0) 32-bit.

Also hangs with Claws 3.7.8 on Ubuntu 10.04 LTS, 32-bit.

What has occurred on all three systems, is that when the icon for HTML is selected, the message window pane goes blank and at that point, Claws uses 100% of the CPU.

This primarily occurs on e-mails received from Staples (U.S.-based office supply retailer.)

Same here, with 3.7.9 from Fedora 14. The process also grabs more and more memory. strace shows nothing but the brk() calls every second or so.

I'll attach the source code of the mail which causes the problem. Perhaps we should report this to gtkhtml, too?

Created attachment 993 [details]
Source code of a mail which causes claws-mail to hang.

Here's a trace of what claws mail was doing during the hang.

#0  0x00007fffeca4d827 in css_value_list_append (list=0x11510b0, 
    element=<value optimized out>, list_sep=<value optimized out>)
    at cssvalue.c:152
#1  0x00007fffeca4cf46 in css_parser_parse_atkeyword (
    str=<value optimized out>, len=<value optimized out>, 
    base_url=<value optimized out>) at cssparser.c:1274
#2  css_parser_parse_stylesheet (str=<value optimized out>, 
    len=<value optimized out>, base_url=<value optimized out>)
    at cssparser.c:1505
#3  0x00007fffeca4e778 in html_document_node_inserted_traverser (t=
    0xe2e760 [HtmlDocument], node=0x10a5010 [DomText]) at htmldocument.c:281
#4  0x00007fffeca4ed31 in html_document_new_node (
    parser=<value optimized out>, node=0x10a5010 [DomText], t=
    0xe2e760 [HtmlDocument]) at htmldocument.c:530
#5  0x0000003301c0e03e in g_closure_invoke (closure=0x10baf10, return_value=
    0x0, n_param_values=2, param_values=0x10a5cd0, invocation_hint=
    0x7fffffff9a70) at gclosure.c:766
#6  0x0000003301c1ee87 in signal_emit_unlocked_R (node=<value optimized out>, 
    detail=0, instance=0xcd1520, emission_return=0x0, instance_and_params=
    0x10a5cd0) at gsignal.c:3252
#7  0x0000003301c287b5 in g_signal_emit_valist (
    instance=<value optimized out>, signal_id=<value optimized out>, 
    detail=<value optimized out>, var_args=<value optimized out>)
    at gsignal.c:2983
#8  0x0000003301c28983 in g_signal_emit (instance=<value optimized out>, 
    signal_id=<value optimized out>, detail=<value optimized out>)
    at gsignal.c:3040
#9  0x00007ffff0206d7e in htmlParseScript (ctxt=0x10baa20) at HTMLparser.c:2902
#10 0x00007ffff020c69b in htmlParseTryOrFinish (ctxt=0x10baa20, 
    chunk=<value optimized out>, size=<value optimized out>, terminate=0)
    at HTMLparser.c:5619
#11 htmlParseChunk__internal_alias (ctxt=0x10baa20, 
    chunk=<value optimized out>, size=<value optimized out>, terminate=0)
    at HTMLparser.c:5945
#12 0x00007fffeca73429 in html_stream_write (stream=0x10b5680 [HtmlStream], 
    buffer=<value optimized out>, size=890) at htmlstream.c:85
#13 0x00007fffeca44d40 in gtkhtml2_show_mimepart_real (_viewer=0x10a3850)
    at gtkhtml2_viewer.c:346
#14 0x00000032ff0435eb in g_timeout_dispatch (source=<value optimized out>, 
    callback=<value optimized out>, user_data=<value optimized out>)
    at gmain.c:3585
#15 0x00000032ff041e33 in g_main_dispatch (context=0x9f6800) at gmain.c:2149
#16 g_main_context_dispatch (context=0x9f6800) at gmain.c:2702
#17 0x00000032ff042610 in g_main_context_iterate (context=0x9f6800, block=1, 
    dispatch=1, self=<value optimized out>) at gmain.c:2780
#18 0x00000032ff0428ad in g_main_context_iteration (context=0x9f6800, 
    may_block=1) at gmain.c:2843
#19 0x000000330914b2c1 in IA__gtk_main_iteration () at gtkmain.c:1325
#20 0x00000000005c3e5d in threaded_run (folder=0xeb60d0, param=0x7fffffffc500, 
    result=0x7fffffffc4f0, func=0x5c68a0 <fetch_env_run>) at imap-thread.c:439
#21 0x00000000005c8ce4 in imap_threaded_fetch_env (folder=0xeb60d0, 
    set=<value optimized out>, p_env_list=0x7fffffffc5e8) at imap-thread.c:2878
#22 0x00000000004d38ab in imap_get_uncached_messages_thread (folder=0xeb60d0, 
    item=0xec46c0, msgnum_list=<value optimized out>) at imap.c:2985
#23 imap_get_uncached_messages (folder=0xeb60d0, item=0xec46c0, 
    msgnum_list=<value optimized out>) at imap.c:3123
#24 imap_get_msginfos (folder=0xeb60d0, item=0xec46c0, 
    msgnum_list=<value optimized out>) at imap.c:4175
#25 0x00000000004b7d70 in folder_item_scan_full (item=0xec46c0, filtering=1)
    at folder.c:2326

Hello? Does anyone ever look at this? By now, claws-mail hangs on each and every mail from three sources (tomtom, alice dsl, some social network).

I guess it's time to have another look at evo again, at least it sucks less hard than thunderbird... :-(

Mail is rendered without problem here, using latest CVS and fancy plugin.

Yes, that's probably because fancy uses webkit instead of gtkhtml.

I tried the latest released version now, and there's some progress there also - the tomtom mails are now rendered without hang. The Alice DSL mails still cause it to hang (I can attach one if the devs are interested).

But since one can now choose between gtkhtml2, dillo and webkit, I switched to webkit (fancy plugin) which renders those two mails ok. I'll check the third kind once one arrives again.

This still occurs with the HTML e-mails from Staples http://www.staples.com/ but it also freezes the Windows version of Claws, I'm currently using 3.9.0cvs12.

Ricardo mentions in Comment 7 that it renders fine with use of the Fancy plugin, but the current Windows version does not include Fancy.

Created attachment 1210 [details]
Top of Staples HTML e-mail using Fancy plugin with Claws 3.7.6 64-bit Debian Linux

Created attachment 1211 [details]
Part of bottom portion of Staples HTML e-mail with Fancy Plugin 64-bit Debian Linux

When using Claws Mail 3.7.6 on 64-bit Debian Linux with the Fancy plugin, the same e-mail doesn't really appear.  All I see are links at the top of the e-mail/page, lots of white space (with black borders) then the standard Staples page footer at the end.  Please see attachments.

the gtkhtml2 plugin has now been dropped and superseded by the Fancy plugin