GNOME Bugzilla – Bug 777642
Selecting conversation with unread mails immediately close it
Last modified: 2019-01-29 05:42:43 UTC
This bug may be related to Bug 765516 and/or has already been reported but I could not find any matching: sometime when I have unread mail(s?) in a conversation and I select it, Geary will mark the mail read but close the conversation immediately. From now here is what I gathered: - it only applies the first time mails are received. Eg. if I mark them unread again and try to reproduce the bug, it never occurs. Maybe it's related to an issue with email not-already-fetched? - I think it happens only if I have at least 2 unread mails. The first one is automatically marked read / conversation is closed / conversation is reopened with the second mail. But I'm unsure here. If the bug is not already reported, I'll try to grab logs and be more attentive to actually conditions of triggering it!
This is new to me, so yeah, some logs would be good :) Note the WK2 port has a few changes that might affect this, so probably worth looking into more on the WIP branch, or on master when it lands.
Until now, when I use --debug I cannot reproduce the issue; I don't know if it's related to some bad timing that happen only in quiet mode or if I only had some bad luck. Looking forward for Bug 775955 :). Anyway I just faced the same bug but a bit different: I saved a draft and continued it a few moments ago - but while I was writing, at some time the composer closed itself. However at that time the header bar shown composer icons (save draft, discard, etc.) and if I clicked on any conversation, the popup "Discard the draft?" was shown. Trying to catch logs…
Created attachment 344497 [details] closing draft OK so I could grab logs for the second issue and can reproduce it: 1) simply save any new mail as draft 2) edit it again… 3) type something in it, then wait around 15sec -> the composer is automatically "closed" (or at least it disappears).
(In reply to Gautier Pelloux-Prayer from comment #3) > > OK so I could grab logs for the second issue and can reproduce it: > > 1) simply save any new mail as draft > 2) edit it again… > 3) type something in it, then wait around 15sec > > -> the composer is automatically "closed" (or at least it disappears). Oh, so I think that's related to how we are handling draft changes - the draft autosave timeout 10s, and there's a short delay in the round trip, which would explain the ~15s wait you're seeing. So maybe when the old draft is deleted, the composer that it associated with is going away as well. This is when you are in the drafts folder, and are editing the draft in an embedded composer, right? If so, then it sounds like a bug or limitation with the draft id handling in ConversationListBox::add_embedded_composer, or nearby. I don't think I'll have time to look at this any time soon, but would good to fix for 0.12, so if have a moment can you take a look at it?
Created attachment 344516 [details] conversation closed on open Thanks Mike for the given pointers. I don't know if I'll have time to investigate this issue right now though. In the mean time I succeeded to grab logs for the conversation closed issue as well, see attached. Do you think these are the same issue or should I open separate bugs?
No problem, thanks for the log. If the conversation doesn't contain a draft and you weren't doing any editing it sounds like a different bug to the draft issue. Let me take a proper look at it when a I have a moment over the next few days though.
So looking at the log, maybe this is what causing the issue: > [deb] 10:49:29 0,072673 app-conversation-set.vala:164: Merging 2 conversations due new email associating with all... > [deb] 10:49:29 0,000182 app-conversation-set.vala:311: Removing email [23126/5407] evaporates conversation [#298] (0 emails) My current theory is that a new message comes in that causes two conversations to be merged into one, and the redundant conversation is removed. If the one that was removed was also the one being displayed at the time, then it will be closed. Does that sound plausible? I'm wondering what kind of emails might cause this to happen? You'd have to have two different messages that both refer to a common, as-yet-unreceived ancestor, but I'm not sure why those would be delivered before the first - maybe some anti-spam tactics like greylisting? If Geary handled this in the past, then Bug 765516 probably did break it, but I'm not sure if did.
BTW, just filed the draft issue as Bug 779115.
OK so I bisected this issue because I am now able to reproduce it. The first commit which has the issue is commit 4b5b2e: > commit 4b5b2ee6e1c84c1320d3c299e964e20512783c88 > Author: Niels De Graef <nielsdegraef@gmail.com> > Date: Thu Dec 8 11:20:59 2016 +0100 > Use "org.gnome.Geary" for the app ID. Bug 766196. It's very strange and I don't understand why yet - but I will try to investigate what exactly makes it happen.
Hey, I still can' repro this, so closing for the moment. If you start using Geary again and manage to, please reopen!