Bug 276893

Summary: Messages not correctly being marked as read when opened
Product: [Applications] kmail2 Reporter: David <StormByte>
Component: generalAssignee: kdepim bugs <kdepim-bugs>
Severity: major CC: aspotashev, asturm, cpigat242, graham.anderson, kdenis, kollix, lnxusr, mpgkde, web
Priority: NOR Keywords: regression
Version: 2.1.0   
Target Milestone: ---   
Platform: Gentoo Packages   
OS: Linux   
Latest Commit: Version Fixed In:
Attachments: Always mark message as read

Description David 2011-07-01 14:44:06 UTC
Version:           2.1.0 (using KDE 4.6.4) 
OS:                Linux

When migrated from Kmail1 (I suppose it happens too when using kmail from scratch), it has a SEVERE problem when marking and counting unread and read messages.
For example, in a folder I created for a mail account, folder list says I have 700 unread messages, but from those 700, only a few are really unread.
Then, that 700 number is the TOTAL messages in that folder, NOT unreaded ones.
But the problem arise too, when I read messages and those are in the same color always and not updating count of unreaded ones.
This is VERY annoying, since when a huge amount of mail is received every day, makes kmail2 very unintuitive and not productive.

What has been with the behaviour of previous kmail in this matter? (Colouring read and unread messages in different ways, counting unread messages intead of total messages, etc..)?

I hope I explained it well, and I marked it as a major bug, since not only it can lead to an accidental data loss if you *think* you read that message and delete it (since it does not mark as read properly), but also because if this behaviour is not fixed, it renders kmail2 to be counterproductive (because I need to spend an extra time in recheck already read messages!).

I think this is a major thing to be fixed in order to keep kmail2 testing up to date.

Reproducible: Always

Steps to Reproduce:
Open kmail2, configure some mail account on it (and create a folder to store that messages), receive messages, and see that unreaded ones are treated in the same way than readed ones

Actual Results:  
- Colours for read and unread messages are the same
- Count of unread messages is wrong, and it counts *all* messages in folders

Expected Results:  
- Different colours for read and unread messages in message list of folder
- Have unread counting fixed

Didn't try yet to have a config of kmail2 from scratch, but since this seems to affect its core, I don't know it will change much this case.
Comment 1 David 2011-07-01 14:47:48 UTC
I add more: Also, the left panel containing the tree of folders is very broken in this matter:
It does not actually count well how much items a folder has in it (be read or unread).
Example: Create a new mail in composer, save it as a draft. Watch what drafts folder properties say: Counter for messages is wrong!
Now delete that draft, and look how this counter is still wrong (in my case, I have 0 drafts, but it says it has 2 unread, 1 total, and 1.2 KiB but it is empty!
Comment 2 David 2011-07-01 14:49:10 UTC
The same goes for every other folders, I recently noted (after submitting comment), that deleting a message in every folder, does not seem to update its counter.
Comment 3 Cédric Bellegarde 2011-07-11 13:28:23 UTC
Can confirm this bug
Comment 4 Torgny Nyblom 2011-07-17 06:18:03 UTC
(In reply to comment #3)
> Can confirm this bug

Which? The original or the appended one in comment #2?

As for the original I cannot confirm and I've been using KMail2 since.. well the beginning.
Comment 5 David 2011-07-27 11:18:58 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > Can confirm this bug
> Which? The original or the appended one in comment #2?
> As for the original I cannot confirm and I've been using KMail2 since.. well
> the beginning.

Did you upgrade from kmail1 or used a fresh kmail2 install? I reported it by using migration wizard and not a clean and fresh install and config.
Comment 6 Torgny Nyblom 2011-07-27 19:08:58 UTC
Both actually.

And again, what bug can you confirm, wrong unread count or wrong total counter?
Comment 7 David 2011-07-27 22:44:12 UTC
Since I reported the bug, I can confirm both two. But I am installing a fresh install of gentoo with kde 4.7.0 and will retest once it is finished with a clean config.
Comment 8 David 2011-08-04 14:13:33 UTC
I retested with a clean system clean config kde 4.7.0 and can confirm both problems:
On one hand the counter problem: Currently it is displaying 45 unread messages (all of those messages are in blue color in messagelist).
It does not matter whether I open a message or whether I right click on folder and select 'Mark all mails as read' option.
On the other hand is the messagelist display:
The most annoying thing is that messages in messagelist keep having blue color instead of changing color to mark them as efectivelly read.

And there is a bit more, when I right click a message and mark it as important, nothing happens however if I click the "exclamation" button at the right part of the message (in messagelist) it is correctly marked as important, so maybe a problem of signal connections?
Comment 9 David 2011-08-04 14:17:09 UTC
Another thing which can be the cause of this too: I saw that in custom colors config, there is no option for 'read message' color, but there is for 'new message', 'unread message', and so on.
So that could be the cause to a message not changing its color after being read??
Comment 10 David 2011-08-17 16:15:08 UTC
Well, since no support is being received from developers, and this is a blockstopper bug from using Kmail, I am switching to another software hoping this will be solved really soon (I loved kmail...)

I will provide an image which will show what I am talking about of this serious regression.

In this image can be seen that I have 166 Unreaded messages on "StormByte" folder, but all of those have already been opened and read!!

Well, this is the image proving it is deadly wrong: http://2.bp.blogspot.com/-Ao7mAZyFiy4/Tkvo24UxS-I/AAAAAAAAACQ/HqUIbH9m1XI/s1600/kmail.png
Comment 11 Cédric Bellegarde 2011-09-06 12:28:54 UTC
Can confirm "wrong unread count ", don't use total count...
Comment 12 Cédric Bellegarde 2011-10-05 08:15:31 UTC

Here screenshot showing what is happening:
- mail1.png: We receivre a new mail, marked as unread, in maildir, we can see mail is marked as unread.
- mail2.png: We read mail in kmail, marked as read in kmail, as unread in maildir and in roundcube
- mail3.png: We read mail again in kmail, marked as read in kmail, as read in maildir and as read in roundcube.

So, it seems kmail (akonadi?) do not append ",S" to mail filename first time we read email.
Comment 13 Cédric Bellegarde 2011-10-05 08:25:09 UTC
Here what happens in logs:

First time i read the message:

processing retrieval request for item 50388  parts: ("RFC822")  of resource: "akonadi_imap_resource_1" 
request for item 50388 succeeded 

Seconde time:

akonadi_imap_resource_1(8209)/libakonadi Akonadi::ItemSync::updateItem: Stored flags  QSet("\SEEN") new flags  QSet()
Comment 14 Cédric Bellegarde 2011-10-05 10:50:01 UTC
Can confirm bug on Archlinux and Kubuntu 11.10
Comment 15 Cédric Bellegarde 2011-10-11 07:19:49 UTC
797	8.360787	IMAP	Request: A000218 UID STORE 3439 FLAGS (\Seen)

Can confirm that akonadi do not send this the first time you read a message...
Comment 16 Cédric Bellegarde 2011-10-11 11:33:59 UTC
Created attachment 64406 [details]
Always mark message as read

Here a patch fixing the issue...

It seems kmail mark mail as read internaly but don't send information to akonadi.

Don't know if it's the best way to fix the bug... But it will give you a information on what's going wrong.
Comment 17 Cédric Bellegarde 2011-10-12 17:40:10 UTC
Ok, i delete all my .kde4 .local and .config directories and now all is working well without previous patch...

WTF ? :-(

Will wait to see if bug appear again or if it's a migration issue or if it was fixed by recent archlinux update (4.7.2-2).
Comment 18 Martin Pagh Goodwin 2012-04-29 19:26:42 UTC
I have just installed Kubuntu 12.04, and initially my mail would work correctly (marking messages as read as I was opening them). I have then been through various contotions of errors with mail import from my old (11.10) home folder, and as a result Kmail no longer marks messages as read when reading them. 

If the reading pane is enabled, I have no problems, but I do not want to use the reading pane.

On a test account I created, where my import went more smoothly, "mark as read when read" works.

Thus a quick fix would be to be able to completely reset Kmail to the pristine state of "just installed"/"new user". Dropping the akonadi database does not seem to impact the problem
Comment 19 Martin Koller 2013-02-10 12:03:47 UTC
I can not reproduce with 4.10.0
Is this still an issue for you with this current version ?
Comment 20 Graham Anderson 2013-03-09 21:03:38 UTC
I still see this bug everyday; Platform Version 4.10.1 "release 552"

All my mail is via imap....
Comment 21 Andreas Sturmlechner 2014-05-16 20:52:26 UTC
Haven't seen that problem in a long time. Others?
Comment 22 Denis Kurz 2016-09-24 18:08:41 UTC
This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present?

If noone confirms this bug for a Framework-based version of kmail2 (version 5.0 or later, as part of KDE Applications 15.12 or later), it gets closed in about three months.
Comment 23 lnxusr 2016-10-21 17:35:41 UTC
This bug is back in version 4:16.04.3.  This is the version I can recall seeing it.
Comment 24 lnxusr 2016-10-21 17:41:44 UTC
(In reply to lnxusr from comment #23)
> This bug is back in version 4:16.04.3.  This is the version I can recall
> seeing it.

OK, it seems there was a delay of some sorts when I set 'Mark selected message as read after' to 0 seconds before it started actually marking them as read after opening.  It's now working.
Comment 25 Denis Kurz 2017-01-08 00:04:58 UTC
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.