GTK+ 2.24.32 / GLib 2.54.3
Locale: en_US.UTF-8 (charset: UTF-8)
Operating System: Linux 4.12.14-lp151.28.25-default (x86_64)
As messages arrive in my INBOX they are immediately being marked as read. This is a significant problems as it's easy to miss an important email.
This is a recent bug - as of my updating to 3.17.4git70.
Also - when viewing a message in the INBOX and a new message arrives, Claws immediately "force moves" to the new message which is then marked as read!
sounds like a filtering rule or a processing rule.
Showing the debug output should help and/or the filtering log. Please attach those.
Created attachment 2022 [details]
Filter log (set to HIGH)
Filter log attached. I have no processing rules set.
Created attachment 2023 [details]
Filter log (set to MEDIUM)
More filtering logging (Medium)
Created attachment 2024 [details]
Filtering rules attached
It happens here in folders other than InBox.
I have found a workaround: If I leave the focus on a folder that seldom receives mail, then claws acts normally (i.e., does not automatically mark any emails from other folders as "read").
This would seem to eliminate the likelihood of the bug being related to filtering - since the filtering continues as usual.
If I put the focus on my default "inbox", then the "inbox" will auto mark emails as being read - and even "grab" the focus from an email being read to a newly arriving email.
Based on the comments from another user, it looks like this "phenomenon" occurs in other folders than the "inbox" (perhaps always the "focused" folder???).
Created attachment 2025 [details]
long filtering log (set to HIGH)
More detail - filtering log (set to HIGH)
> This is a recent bug - as of my updating to 3.17.4git70.
What version did you update from?
(BTW, I have never seen this behaviour.)
The filtering logs don't seem to tell anything useful. Can you attach debug output from when this happens?
Previous was "version 3.17.3git103"
Created attachment 2026 [details]
The Debug output was stopped shortly after I was viewing one inbox email - and was "forced" into the next email before I finished reading the first.
> Previous was "version 3.17.3git103"
That's about 10 months ago, and some 200+ commits...
Let's try to narrow it down...
In the general preferences, on the 'Receiving' page, do you have 'go to inbox' after receiving new mai set?
On the Summaries page, Message List tab, what settings do you have for 'Set message selection when entering folder'?
Also on the Summaries page, Message List tab, what do you have checked under 'Open message when selected'?
Same place, what settings do you have on the 'Mark message as read' frame?
Not the OP, but experiencing the same issue;
I think I first noticed the change after the release of 3.17.4, but I can't recall exactly when. So 70 commits or so. That's still a lot, I know. Sorry.
Message selection on entering folder is;
Oldest unread email
Oldest marked email
Oldest new email
Newest email in list
However, if I put 'None' at the top of the list, the problem doesn't occur.
Hopefully, I'm not throwing in red herrings.
> > Previous was "version 3.17.3git103"
> That's about 10 months ago, and some 200+ commits...
Sorry, I tend to "stick" with a version that proves stable and works for me ;)
> Let's try to narrow it down...
> In the general preferences, on the 'Receiving' page, do you have 'go to
> inbox' after receiving new mai set?
No - but "Update all folders is set"
> On the Summaries page, Message List tab, what settings do you have for 'Set
> message selection when entering folder'?
> Also on the Summaries page, Message List tab, what do you have checked under
> 'Open message when selected'?
Open message when selected
> Same place, what settings do you have on the 'Mark message as read' frame?
Mark message as read
when selected, after 0 seconds
Show "no unread (or new) message" dialog
Execute immediately when moving or deleting messages
Confirm when changing color labels
My setup is probably not the same than OP’s one, but i also experience the same « incoming mails are marked as read », since few weeks (maybe a month or two)
I usually keep last checked out Git version before i update to the latest one so i’ll give it a try (no at home right now).
Sorry for the lack of hard facts, but i’ll send some later.
this should be fixed by commit ea54db54dfda96918926f996483b1753a8347d0e, 3.17.4git73.
Please test and report.
there was a mistake in ea54db54dfda96918926f996483b1753a8347d0e
so yu need that and 5f1063a0c8ee9b782504cf93c967c4541355cd1e, bringing the version up to 3.17.4-74
Have been testing "version 3.17.4git74" this morning. After several hours appears to work great. Thanks Paul!
Well, I just had the time to pull git72 yesterday, and it looked like it fixed the problem for me.
So maybe part of the fix was already in , and git73 and git74 were additional fixes to nail the bug for good ?
Anyway, thank you all.
Ok, it only looked fixed , but it was not (in git72), sorry for the noise.
Running git74 right now, will see how it runs.
Running just fine since upgrade (10 days).
Problem's fixed for me, thanks much !