Bug 1313055 - attachments list empty on first open of email
attachments list empty on first open of email
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: evolution (Show other bugs)
23
x86_64 Linux
unspecified Severity low
: ---
: ---
Assigned To: Milan Crha
Fedora Extras Quality Assurance
:
: 1322759 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-29 15:07 EST by bartmon
Modified: 2016-03-31 12:08 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-03-02 05:19:54 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
blank attachment list (31.06 KB, image/png)
2016-02-29 15:07 EST, bartmon
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 762975 None None None 2016-03-02 05:19 EST

  None (edit)
Description bartmon 2016-02-29 15:07:47 EST
Created attachment 1131685 [details]
blank attachment list

* 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.
Comment 1 Milan Crha 2016-03-02 05:19:54 EST
Thanks for a bug report. I guess it's some issue between WebKitGTK3 and gtk+ itself. I can be wrong though. Anyway, there is a plan to port 3.22 to use webkit2, instead of webkit1, where this part will be done differently. Due to that I'd rather not investigate the issue as of now, but keep it for testing after the port is over.

I'm moving this to upstream, for better visibility. Please see [1] for any further updates.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=762975
Comment 2 Milan Crha 2016-03-31 12:08:43 EDT
*** Bug 1322759 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.