This bug should be fixed with revision 81d97c694c2b068327505b3735f75782c70eaa6e (included in 1.3.7).

Sorry, but in SOGo 1.3.8a you get wrong read/unread marks too.
So it is not completely fixed yet.

I checked with firebug, and it often doesn't send markMessageRead on opening new received emails.
Perhaps you should send it always and skip your logic when not to do it. That's not much of overhead and this annoying bug would be fixed.

I can't reproduce this bug.

Could you set SOGoUIxDebugEnabled to YES and see if you have any errors in the log console?

I assume you don't have any error in the Firefox console?

Sorry, I can't enable SOGo debug because we are not using SOGo now.
Perhaps the reporter Christian Mack can do it.

I enabled "SOGoUIxDebugEnabled", but there I only see

updating quotas 58367/1000000

messages when changing folders. That's OK, as this account has a quota of 1 GB with 0000083:0000058 MB used.

And yes, I don't see any errors in the Firefox console too.

As I said before, SOGo scripts seems to not always send "markMessageRead" requests to the backend.

I tested this with 2.0 beta too. Same behavior.

BTW:
I tested this with a folder containing 185 emails in it.
I marked all unread with thunderbird.
Now open each in SOGo web client one after one (as if someone would read them).
Afterwards they all show as read in SOGo.
Then logout and re-login (not necessary, just to speed up the reload).
After that I had 69 unread messages in that folder.

I tried that test now (SOGO-1.3.8b and dovecot-1.2.15).
It looks that strange behavior depends on speed of clicking on every single message. When I'm clicking very fast, content of some message is not displayed (but message is marked as read) and I'm clicking on following message. When I leave that folder and going back into it, all that "very fast clicked" messages are marked as unread - what is right, because their content was not displayed ;-)
If this is the matter of that problem, then SOGo would mark message as read after its content is transfered and displayed, not before.

When I clicked slowly and contents of all messages were displayed, I didn't found that problem.

The action "markMessageRead" is only called if the message has already been loaded and you click on the read/unread "dot" (or if you use the contextual menu). The "view" action is enough to mark the message as read.

What is your IMAP server? What version?

Guys you better hurry to provide answers to this ticket as 1.3.9 is real close to be released - if of course, you want a potential fix in for v1.3.9.

We have a Cyrus 2.3.16.

When using a Thunderbird client in parallel to SOGo I can see which messages get marked as read immediately.

When clicking on a mail to read it no "\Seen" gets set, but if you take the next message, the message you looked at before will get marked as "\Seen". If you do this rapidly, not all messages are marked as \Seen.

If it helps, I can make a video showing this behaviour...

When you switch from one message to the other very rapidly, does the "view" action is still performed? (look at your sogo logs)

Views are all getting through:
134.34.1.194 - - [25/Oct/2011:13:28:37 GMT] "POST /SOGo/so/pop05579/Mail//0/folderINBOX/126425/view?noframe=1 HTTP/1.0" 200 1372/0 0.123 3993 65% 0
134.34.1.194 - - [25/Oct/2011:13:28:37 GMT] "POST /SOGo/so/pop05579/Mail//0/folderINBOX/126422/view?noframe=1 HTTP/1.0" 200 1215/0 0.123 4517 73% 0
134.34.1.194 - - [25/Oct/2011:13:28:38 GMT] "POST /SOGo/so/pop05579/Mail//0/folderINBOX/126421/view?noframe=1 HTTP/1.0" 200 1127/0 0.438 3352 66% 0
134.34.1.194 - - [25/Oct/2011:13:28:39 GMT] "POST /SOGo/so/pop05579/Mail//0/folderINBOX/126420/view?noframe=1 HTTP/1.0" 200 3038/0 0.245 9444 67% 0
134.34.1.194 - - [25/Oct/2011:13:28:39 GMT] "POST /SOGo/so/pop05579/Mail//0/folderINBOX/126424/view?noframe=1 HTTP/1.0" 200 1707/0 0.122 5295 67% 0
134.34.1.194 - - [25/Oct/2011:13:28:39 GMT] "POST /SOGo/so/pop05579/Mail//0/folderINBOX/126423/view?noframe=1 HTTP/1.0" 200 2461/0 0.282 10653 76% 8K
134.34.1.194 - - [25/Oct/2011:13:28:39 GMT] "POST /SOGo/so/pop05579/Mail//0/folderINBOX/126423/view?noframe=1 HTTP/1.0" 200 2461/0 0.286 10653 76% 56K
134.34.1.194 - - [25/Oct/2011:13:28:41 GMT] "POST /SOGo/so/pop05579/Mail//0/folderINBOX/126424/view?noframe=1 HTTP/1.0" 200 1707/0 0.123 5295 67% 0
134.34.1.194 - - [25/Oct/2011:13:28:42 GMT] "POST /SOGo/so/pop05579/Mail//0/folderINBOX/126425/view?noframe=1 HTTP/1.0" 200 1372/0 0.119 3993 65% 0

Still no \Seen set, (i popped up a Thunderbird to verify). After clicking on Reload ("Abrufen") on SOGo, all messages appear unread. Again, all view requests were done, still the Seen flags get not updated immediately.

After changing folders, many \Seen get applied so Thunderbird sees most of the messages as "read". The Seen flag is not updated immediately when "view" is called.

In my understanding, the "view" should automatically update the appopriate message as Seen.

Is there a problem with UID vs ID in the IMAP part? I'll try to trace the IMAP conversation to see what he does. Give me 30 minutes.

SOGo does:

7 uid fetch 126427 (FLAGS ENVELOPE BODYSTRUCTURE RFC822.SIZE RFC822.HEADER)

and

8 uid fetch 126427 (body[text])

Answer:

This clears the RECENT status of a message but not the status of being UNSEEN.

The message still lacks the \Seen-Flag - so thunderbird et.al. will not treat the message as read, neither does SOGo.

The missing line is (which would DO the task):

UID STORE 126427 +FLAGS (\Seen)

Sometimes SOGo sends out this line, sometimes not. You HAVE to STORE a Seen-Flag to mark it es read, a simple FETCH is not sufficient - at least Cyrus treats it like this.

The funny behaviour is that our Cyrus seems to give out FLAGS (\Seen) when in fact it is unseen (after the FETCH BODY).

There are only two ways to correct this:

• We're upgrading to Cyrus 2.4.12 in December, hopefully \Seen-Handling is better (no false \Seen flag after doing a FETCH) and/or
• making SOGo ALWAYS STORE the \Seen-Flag after having FETCHed a message, so consistency is always given.

For your information, from RFC 3501 (IMAP 4rev1) :

6.4.5. FETCH Command
..
BODY[<section>]<<partial>>
..
The \Seen flag is implicitly set; if this causes the flags to
change, they SHOULD be included as part of the FETCH responses.

Try Cyrus 2.4.12, it works great.