GNOME Bugzilla – Bug 681431
Expand attachment bar hides headers
Last modified: 2013-09-13 01:09:00 UTC
I just realized that expanding large attachment bar can hide top headers and doesn't show all attachments in an icon view. Steps: a) have a digest message, with about 20 messages b) open it in a separate window (double-click) c) see the top attachment bar shows something like: [+] 20 Attachments [Save all] d) click the [+] See how the attachment bar changed its height and how it hid the top headers. Changing window size to maximize made show top two headers, but still not all. This is reproducible with webkit 1.9.5 too.
This one is still there in master (3.5.90+), would be nice to fix before 3.6. On a side note, I noted that when I see such message (many attachments) in the preview pane, with the attachments list folded (the list at the right of the Save All button), and move to another mail, I see that list completely unfolded for a second or two, before the new email is shown. It also happens with as few attachments as 1 or 2, very noticeable when they are big. If nothing else, it's disturbing and quite ugly.
Created attachment 222639 [details] [review] Fix This patch fixes both issues mentioned in this bug. The height of the attachment bar is now correctly detected by obtaining the value using gtk_widget_get_preferred_height_for_width() rather then gtk_widget_get_preferred_height(). The attachment bar was always completely expanded when switching emails because someone stupid (probably me) was calling gtk_widget_show_all() after displaying the 'Retrieving message...' message (during that time WebKitWebView still contains the GtkWidgets from previous message).
Seems to work fine here, please commit. Thanks.
Works for me too (both issues). Yet, I noticed that when the attachment bar is unfolded, I can barely scroll. With ~30 attachments, it takes seconds to scroll down, with evo and Xorg fighting for the CPU. It's much faster with the bar folded.
Comment on attachment 222639 [details] [review] Fix Committed to git master as 0d4a549 http://git.gnome.org/browse/evolution/commit/?id=0d4a549502104ffd25d129a9599e97f97582741f
Thanks for testing, I believe the problem with crappy performance when scrolling is because of in-effective relayouting and redrawing of the widget - the more complex the widget, the slower it is. I believe that 30 attachments is not an usual use-case though so please open a new bug report for the performance issue and I'll try to deal with it later (let's say for 3.6.1 :-)
I'm afraid it's rather webkit issue, than evolution's.