GNOME Bugzilla – Bug 762975
Attachments list empty on first open of email
Last modified: 2016-08-11 09:07:34 UTC
Moving this from a downstream bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1313055 * Description of problem: When default view of attachments is set to list view, after loading a remote email (confirmed with IMAP | EWS) for the first time will show an empty list. Closing and reopening the list shows the attachments. * Version-Release number of selected component (if applicable): evolution-3.18.5.1-1.fc23.x86_64 * How reproducible: Always * Steps to Reproduce: 1. Set the default view of attachments to List View (not Icon View) by opening an email with attachment and selecting List View when attachment list is expanded 2. Open an uncached email (works for me with en email unopened in evolution session) 3. Expand the attachment list. It should be empty * Actual results: Attachment list is empty in List View. * Expected results: Attachment list populated in List View on first expansion. * Additional info: On request.
Let's investigate this after the webkit2 port (bug #751588), where this will be done differently.
*** Bug 763721 has been marked as a duplicate of this bug. ***
I see there are people using this, as there are duplicates both here and downstream. I tried to look at this, just in case it would be some minor thing, but I didn't find anything fully functional. I added some debugging prints, namely to attachment_tree_view_render_size(), and it is called as it should, even in some drawing code, still the GtkTreeView rejects to draw the data this function gave it. I see it being called also when I hover mouse about the place where the lines should be. I noticed that the mail_display_plugin_widget_resize() is called also in an "size-allocate" signal callback, which can be a problem, thus I added a code to postpone the processing into an idle callback, but it didn't help, not always. A good news is that the mail_display_plugin_widget_resize() is gone in the webkit2 port, but the bad news is that this is still broken in the current stable (and even master, as of today). I suspect that some signal processing broke this in a way that gtk+ is confused and doesn't paint into the GtkTreeView::bin_window as it should, but I do not know the drawing code enough to tell for sure. The GtkIconView doesn't suffer of this, which can be a clue. Maybe it would worth it to investigate the issue from the gtk+ side, because my debugging showed that all the drawing code is called, only the GtkTreeView content is not shown to the user for some reason. I'm reassigning it to the gtk+ developers for their opinion. I'm fine if they return it back to the evolution. I also made a little change in the evolution (commit_4a412a8 [1]), but it doesn't seem to have any real influence on this content drawing issue. [1] https://git.gnome.org/browse/evolution/commit/?id=4a412a8
This is fixed by the port to WebKit2 on the Evolution side (for 3.21.90+), thus I'm closing this. It could be some oddity due to a gtk+ widget being placed inside WebKitWebView of the WebKit1.