Bug 4277 - INBOX being "read" automatically - being marked as read before being selected
Summary: INBOX being "read" automatically - being marked as read before being selected
Status: RESOLVED FIXED
Alias: None
Product: Claws Mail
Classification: Unclassified
Component: UI/Message View (show other bugs)
Version: 3.17.5
Hardware: PC Linux
: P3 normal
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2019-11-18 19:26 CET by lbickley
Modified: 2019-12-07 22:07 CET (History)
0 users

See Also:


Attachments
Filter log (set to HIGH) (39.23 KB, text/plain)
2019-11-19 19:09 CET, lbickley
no flags Details
Filter log (set to MEDIUM) (343.66 KB, text/plain)
2019-11-19 19:14 CET, lbickley
no flags Details
Filtering Rules (7.98 KB, text/plain)
2019-11-19 19:20 CET, lbickley
no flags Details
long filtering log (set to HIGH) (48.17 KB, application/gzip)
2019-11-20 01:18 CET, lbickley
no flags Details
Debug output (69.83 KB, application/gzip)
2019-11-20 17:26 CET, lbickley
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description lbickley 2019-11-18 19:26:02 CET

    
Comment 1 lbickley 2019-11-18 19:29:36 CET
System Information
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)
version 3.17.4git70

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.
Comment 2 lbickley 2019-11-18 19:33:50 CET
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!
Comment 3 Paul 2019-11-18 22:40:14 CET
sounds like a filtering rule or a processing rule.

Showing the debug output should help and/or the filtering log. Please attach those.
Comment 4 lbickley 2019-11-19 19:09:28 CET
Created attachment 2022 [details]
Filter log (set to HIGH)

Filter log attached. I have no processing rules set.
Comment 5 lbickley 2019-11-19 19:14:31 CET
Created attachment 2023 [details]
Filter log (set to MEDIUM)

More filtering logging (Medium)
Comment 6 lbickley 2019-11-19 19:20:47 CET
Created attachment 2024 [details]
Filtering Rules

Filtering rules attached
Comment 7 brad@fineby.me.uk 2019-11-19 19:43:35 CET
It happens here in folders other than InBox.
Comment 8 lbickley 2019-11-19 23:46:15 CET
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???).
Comment 9 lbickley 2019-11-20 01:18:54 CET
Created attachment 2025 [details]
long filtering log (set to HIGH)

More detail - filtering log (set to HIGH)
Comment 10 Paul 2019-11-20 08:09:23 CET
> 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.)
Comment 11 Paul 2019-11-20 08:15:10 CET
The filtering logs don't seem to tell anything useful. Can you attach debug output from when this happens?
Comment 12 lbickley 2019-11-20 15:36:16 CET
Previous was "version 3.17.3git103"
Comment 13 lbickley 2019-11-20 17:26:08 CET
Created attachment 2026 [details]
Debug output

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.
Comment 14 Paul 2019-11-20 19:12:57 CET
> 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?
Comment 15 brad@fineby.me.uk 2019-11-20 19:45:51 CET
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.
Comment 16 lbickley 2019-11-20 19:57:59 CET
> > 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
 Always
 
> 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
  Assume 'Yes'
    
 Execute immediately when moving or deleting messages
 
 Confirm when changing color labels
 
 Show tooltips
Comment 17 Philippe Gramoull 2019-11-23 23:09:11 CET
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.

Cheers,
Comment 18 Paul 2019-11-25 12:54:29 CET
this should be fixed by commit ea54db54dfda96918926f996483b1753a8347d0e, 3.17.4git73.

Please test and report.
Comment 19 Paul 2019-11-25 12:59:19 CET
there was a mistake in ea54db54dfda96918926f996483b1753a8347d0e

so yu need that and 5f1063a0c8ee9b782504cf93c967c4541355cd1e, bringing the version up to 3.17.4-74
Comment 20 lbickley 2019-11-25 17:15:49 CET
Have been testing "version 3.17.4git74" this morning. After several hours appears to work great. Thanks Paul!
Comment 21 Philippe Gramoull 2019-11-25 23:54:33 CET
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 ?

Just curious.

Anyway, thank you all.

Philippe
Comment 22 Philippe Gramoull 2019-11-26 00:37:19 CET
re,

Ok, it only looked fixed , but it was not (in git72), sorry for the noise.

Running git74 right now, will see how it runs.

Thanks,

Philippe
Comment 23 Philippe Gramoull 2019-12-07 22:07:22 CET
Hi,

Running just fine since upgrade (10 days).

Problem's fixed for me, thanks much !

Cheers,

Philippe