*** Bug 2982 has been marked as a duplicate of this bug. ***

BTW, the same goes when deleting emails; it seems they aren't synched back to
the server. Sorry for the spam ;)

Comment 3 Alan Bruce 2008-04-17 20:54:58 UTC

(OS2008) Version W15, using imap.gmail.com:

When Modest alerts me to new messages in the panel, and I open the e-mail from
the flashing panel notification box, the e-mail is NOT marked read on the GMail
IMAP server. However, when I read the e-mail from the main Modest window, the
e-mail is properly marked as read.

Comment 4 Alan Bruce 2008-04-20 03:44:45 UTC

*** This bug has been confirmed by popular vote. ***

Comment 5 Andre Klapper 2008-08-01 12:30:55 UTC

Alan, I think your issue is a different one. You talk about opening mail from
the panel notification. In general, please file seperate bug reports instead of
"hijacking" bug reports (though in this case, your issue is described as bug
3005 already). Thanks. :)

Comment 6 Alan Bruce 2008-08-04 02:59:27 UTC

Sorry. Not trying to hijack anything. I have removed my vote for this bug.
Looking forward to Modest coming out of early beta, perhaps in 2009?

Comment 7 Andre Klapper 2008-10-01 15:46:55 UTC

Michiel, is this still an issue with 4.2008.36-5?
Which exact version of Dovecot is this?

Can you provide a debug log of the connection to the mail server when this
happens?
Please start a X Terminal window and enter
    export "CAMEL_DEBUG"="all"
to enable the debug mode of the mail library. After that, enter
    /usr/bin/maemo-summoner /usr/bin/modest.launch showui > log 2>&1
to start the email application. Then try to connect to the mail server. Attach
the logfile named "log" here (please check for confidential data before
attaching).

This is with dovecot version 4.69-9 from Debian. It seems Modest works
correctly now as I can't reproduce the issue. I will be testing Modest some
more and come back to you.

Seems like I can go back to Modest from Claws-mail this way :)

Ah, I reacted too soon; it seems that if I give Modest some time and switch
away from a folder where I read e-mails, it generally marks mails correctly as
`read'; however, today I also had one mail staying unread (this was also the
single message in that folder I read).

I'll be logging my actions later and hope to post something useful here.

Comment 10 Andre Klapper 2008-10-27 16:49:58 UTC

(In reply to comment #9)
> I'll be logging my actions later and hope to post something useful here.

Any news?

Comment 11 Andre Klapper 2009-04-09 17:34:55 UTC

Closing this bug report as no further information has been provided. Please
feel free to reopen this bug if you can provide the information asked for/if
you can still reproduce this. Thanks!

(In reply to comment #11)
> Closing this bug report as no further information has been provided. Please
> feel free to reopen this bug if you can provide the information asked for/if
> you can still reproduce this. Thanks!

This bug is still an issue for me. I'll provide a test account soon.

I'm not able to reopen this bug. What I have to do for doing this?

Btw. there is the same issue for mails marked as deleted on dovecot servers.
I'll make an other bug for this issue too as far as i have some tiime for this.

Please reopen this bug. Thanks

Comment 13 Andre Klapper 2009-04-29 12:33:49 UTC

(In reply to comment #12)
> I'm not able to reopen this bug. What I have to do for doing this?

Ping me. :)

> Please reopen this bug. Thanks

Done.

Okay, now I can reproduce this bug in a stable way:

1. Send an email to the email account you are using on your tablet.
2. open modest (native email application) and receive emails.
3. select the new e-mail you sent in step 1. -> email opens in a new window.
4. open an other email client on your notebook or desktop
5. receive emails for the same email account and have a look into the list of
emails in the inbox
EXPECTED OUTCOME: mail is marked as read
ACTUAL OUTCOME: mail is _not_ marked as read
6. Close the email window what has been open in step 3.
7. Have a look into the list of emails in the inbox of the desktop mail client
EXPECTED OUTCOME: mail is marked as read
ACTUAL OUTCOME: mail is _not_ marked as read
8. close modest on the tablet completely
7. Have a look into the list of emails in the inbox of the desktop mail client
EXPECTED OUTCOME: mail is marked as read
ACTUAL OUTCOME: mail *is marked* as read

So the bug happens only if modest application is not closed.

Deleting emails works fine (I don't have to close modest completely).

You can use a test account on my dovecot server to reproduce this problem:
Account: modestbug@ju-key.de
Server: df-h.de
Password: everything in the localpart of the email address (everything left of
the @)

My last question is now:
Can somebody verify that this not happens on a non-dovecot server? E.g.
google-imap or others.

Comment 15 Eric Warnke 2009-05-06 15:58:27 UTC

I can't confirm, but it's seems like the same behavior I was seeing in
gmail-imap.  I also was seeing deleted emails were not marked as read which is
a problem in gmail-imap since deletion is archiving and not a traditional
delete.

(In reply to comment #14)
> Can somebody verify that this not happens on a non-dovecot server? E.g.
> google-imap or others.

Yes, I've seen it happen on cyrus imapd as well.  I think modest tries to
optimise network usage by queueing up the message flag updates and sending them
all at once when the session is closed.

Comment 17 Andre Klapper 2009-05-26 12:54:27 UTC

Testing this again with Modest from trunk highly welcome:
https://git.maemo.org/projects/modest/gitweb?p=modest

Comment 18 Andre Klapper 2009-06-08 10:44:38 UTC

Anybody able to reproduce this in Modest git trunk in Fremantle SDK?

(In reply to comment #18)
> Anybody able to reproduce this in Modest git trunk in Fremantle SDK?

Yes (well, a couple of weeks old).  \Seen flags are not STOREd when a message
is "read", but only when leaving a folder, closing modest etc.  It's a bit
better than Diablo where changing folders doesn't trigger the update.

Comment 20 Andre Klapper 2009-06-16 14:35:18 UTC

(In reply to comment #19)
> > Anybody able to reproduce this in Modest git trunk in Fremantle SDK?
> Yes (well, a couple of weeks old).  \Seen flags are not STOREd when a message
> is "read", but only when leaving a folder, closing modest etc.  It's a bit
> better than Diablo where changing folders doesn't trigger the update.

Hmm, that sounds more like a design decision than a bug to me. It's similar in
GNOME Evolution for example...


Sergio, can you comment on this?

(In reply to comment #19)
> (In reply to comment #18)
> > Anybody able to reproduce this in Modest git trunk in Fremantle SDK?
> 
> Yes (well, a couple of weeks old).  \Seen flags are not STOREd when a message
> is "read", but only when leaving a folder, closing modest etc.  It's a bit
> better than Diablo where changing folders doesn't trigger the update.
> 

Indeed messages are marked as read in such situations. It's just a matter of
optimizing network usage. We only set a flag in the mail header, and once the
user leaves the folder then we refresh the flags in the server.

(In reply to comment #21)
> (In reply to comment #19)
> > (In reply to comment #18)
> > > Anybody able to reproduce this in Modest git trunk in Fremantle SDK?
> > 
> > Yes (well, a couple of weeks old).  \Seen flags are not STOREd when a message
> > is "read", but only when leaving a folder, closing modest etc.  It's a bit
> > better than Diablo where changing folders doesn't trigger the update.
> > 
> 
> Indeed messages are marked as read in such situations. It's just a matter of
> optimizing network usage. We only set a flag in the mail header, and once the
> user leaves the folder then we refresh the flags in the server.

If I select an email via IMAP modest normaly have to download the message body.
So the _is_ a connection to the server. Why modest can not mark this message as
read in the same server-client dialogue?

(In reply to comment #22)
> (In reply to comment #21)
> > (In reply to comment #19)
> > > (In reply to comment #18)
> > > > Anybody able to reproduce this in Modest git trunk in Fremantle SDK?
> > > 
> > > Yes (well, a couple of weeks old).  \Seen flags are not STOREd when a message
> > > is "read", but only when leaving a folder, closing modest etc.  It's a bit
> > > better than Diablo where changing folders doesn't trigger the update.
> > > 
> > 
> > Indeed messages are marked as read in such situations. It's just a matter of
> > optimizing network usage. We only set a flag in the mail header, and once the
> > user leaves the folder then we refresh the flags in the server.
> 
> If I select an email via IMAP modest normaly have to download the message body.
> So the _is_ a connection to the server. Why modest can not mark this message as
> read in the same server-client dialogue?

For a very easy reason. Imagine that after opening a folder, you read a couple
of messages, delete some of them and mark as unread another ones. All those
operations would require, with the current implementation, a single call to the
server to refresh the folder instead one call per operation.

> > If I select an email via IMAP modest normaly have to download the message body.
> > So the _is_ a connection to the server. Why modest can not mark this message as
> > read in the same server-client dialogue?
> 
> For a very easy reason. Imagine that after opening a folder, you read a couple
> of messages, delete some of them and mark as unread another ones. All those
> operations would require, with the current implementation, a single call to the
> server to refresh the folder instead one call per operation.

OK that sounds good. But what I can do to realize the following scenario:

I open modest early in the morning and close it late in the evening. Between
morning and evening I check my email also on at least two other computer
clients. It would be great if I could see the emails I read in modest as marked
as read in the computer mail clients too. At the moment I always see these
mails as unread in the non tablet clients.

I imagine the most common usage scenario is probably one account with messages
only delivered to INBOX, so modest is likely to be sitting in the INBOX view
all day and not updating the folder.

How about a compromise:  keep the current behaviour, but also trigger updates
when IDLE terminates and/or when the automatic periodic retrieval kicks in.

(In reply to comment #23)
> Imagine that after opening a folder, you read a couple
> of messages, delete some of them and mark as unread another ones. All those
> operations would require, with the current implementation, a single call to the
> server to refresh the folder instead one call per operation.

Actually, message deletions do happen in realtime with the current (Fremantle,
haven't tested Diablo) implementation.

To be honest I'm not convinced this optimisation is worth the hassle (bug 2536
is partially related to this).  Bandwidth-wise the savings are not too
significant (even less so with TLS compression), and the extra round-trips
aren't a big issue with claws, even on high-latency (cellular) connections.

(In reply to comment #26)
> (In reply to comment #23)
> > Imagine that after opening a folder, you read a couple
> > of messages, delete some of them and mark as unread another ones. All those
> > operations would require, with the current implementation, a single call to the
> > server to refresh the folder instead one call per operation.
> 
> Actually, message deletions do happen in realtime with the current (Fremantle,
> haven't tested Diablo) implementation.

Yes because we transformed a delete into a delete+sync due to some
specifications.

Comment 28 Andre Klapper 2009-09-30 16:33:24 UTC

So what is the status here? Can somebody summarize the exact steps and
conditions to trigger this in Fremantle?

(In reply to comment #28)
> Can somebody summarize the exact steps and conditions to trigger this in
> Fremantle?

1. Configure modest and another client with the same IMAP account.
2. Start modest.
3. Open the account configured in step 1.
4. Open INBOX.
5. Read a few unread messages, or mark some unread messages read (or vice
versa).  Do not exit INBOX.
6. Open the account with the other client and check the read status of the
messages modified in step 5.

(In reply to comment #29)
> (In reply to comment #28)
> > Can somebody summarize the exact steps and conditions to trigger this in
> > Fremantle?
> 
> 1. Configure modest and another client with the same IMAP account.
> 2. Start modest.
> 3. Open the account configured in step 1.
> 4. Open INBOX.
> 5. Read a few unread messages, or mark some unread messages read (or vice
> versa).  Do not exit INBOX.
> 6. Open the account with the other client and check the read status of the
> messages modified in step 5.
> 

People usually complain about this. Thing is that we don't save the header
flags to the server until the user closes the headers window. We do that in
order to save bandwith/power and perform a single folder_sync() instead of one
per each change.

Does the suggestion in comment 25 make sense?  Additionally, a flags update
could be done when a message is deleted, when the user manually requests a
"Send ^& receive" and when a new IP connection is established (the latter may
already be the case, I don't know how to test that in scratchbox).

(In reply to comment #31)
> Does the suggestion in comment 25 make sense?  Additionally, a flags update
> could be done when a message is deleted, when the user manually requests a
> "Send ^& receive" and when a new IP connection is established (the latter may
> already be the case, I don't know how to test that in scratchbox).
> 

Yeah that makes a lot of sense. Actually there is an internal bug about that.

Comment 33 Andre Klapper 2009-10-01 13:25:13 UTC

(In reply to comment #32)
> Yeah that makes a lot of sense. Actually there is an internal bug about that.

None I can find when searching for "flag delet" internally.
Sergio, got six digits to share with me so I can subscribe internally (or just
CC me)? :-)

*** Bug 6162 has been marked as a duplicate of this bug. ***

Comment 35 Andre Klapper 2009-11-19 16:58:16 UTC

(In reply to comment #32)
> Yeah that makes a lot of sense. Actually there is an internal bug about that.

Sergio, got an int number?

Comment 36 Andre Klapper 2010-01-04 20:47:30 UTC

Sergio, do you have an internal bug number?

(In reply to comment #36)
> Sergio, do you have an internal bug number?
> 
I think 140509 could be one

Comment 38 Andre Klapper 2010-01-07 15:35:01 UTC

Lucas: You've set the Version up - if this still happens in PR1.1, please
reopen.


This has been fixed in package
modest 3.1.12+0m5
which is part of the internal build version
2.2009.46-16
(Note: 2009 is the year, and the number after is the week.)

A future public update released with the year/week later than this internal
build version will include the fix. (This is not always already the next public
update.)
Please verify that this new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.


To answer popular followup questions:
 * Nokia does not announce release dates of public updates in advance.
 * There is currently no access to these internal, non-public build versions.
   A Brainstorm proposal to change this exists at
http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/

(In reply to comment #38)
> Lucas: You've set the Version up - if this still happens in PR1.1, please
> reopen.

I may have tested the wrong thing.  What is the fix exactly, ie when are the
flags expected to be stored now?

Comment 40 Andre Klapper 2010-01-14 12:27:46 UTC

The problem reported here should be fixed in the update released today for
public: The Maemo5 update version 2.2009.51-1 (also called "PR1.1" sometimes).
Please leave a comment if the problem is not fixed for you in this update
version.

Comment 41 Alan Bruce 2010-01-14 20:21:31 UTC

Sorry, just tested this when I saw it in the list of "fixed" bugs... Still
happening for me in 51-1. (Google IMAP)

Are you sure?, note that in Gmail for example you have to reload the page to
see the updated state

For me it works in this way now:

(I always access the account via IMAP)
1. Open modest
2. select a folder inside of my inbox called "folder1" -> in folder1 are 3
messages marked as unread
3. open the same folder using Thunderbird on my PC -> in folder1 are 3 messages
marked as unread
4. open the first unread message using modest
5. In Thunderbird switch to an other folder and back to folder1 -> in folder1
are 3 messages marked as unread
6. modest: go to the next unread message using the arrow key on the bottom of
the message window
7. In Thunderbird switch to an other folder and back to folder1 -> in folder1
are 3 messages marked as unread
8. Modest: go back to the messages list in folder1 using the icon in the upper
right corner
9. In Thunderbird switch to an other folder and back to folder1 -> in folder1
are 3 messages marked as unread
10. Modest: use again the button in the uppr right corner to go back to the
list of folders in the account.
11. In Thunderbird switch to an other folder and back to folder1 -> in folder1
are 1 messages marked as unread

(I know there is no "mark as unread" flag but I thought it was more simple to
describe it in this way).

ACTUAL OUTCOME:
See steps 3., 5., 7., 9., 11.

Expected Outcome: 
The result of step 11. should be also visible in step 7. and 9.

Comment 44 Alan Bruce 2010-01-19 21:06:23 UTC

Re: Comment #42

I am sure. GMail webmail does not show messages that I have read on my N900 as
being read.

Is there a configuration file that I can delete to see if the problem is old
pre 51-1 settings?

(In reply to comment #44)
> Re: Comment #42
> 
> I am sure. GMail webmail does not show messages that I have read on my N900 as
> being read.
> 
> Is there a configuration file that I can delete to see if the problem is old
> pre 51-1 settings?
> 

No, there shouldn't be any problem with your pre 51-1 settings

Comment 46 Andre Klapper 2010-02-09 18:07:18 UTC

Alan: We're a bit stuck here as Sergio simply cannot reproduce this. :-/

Comment 47 Alan Bruce 2010-02-10 00:57:07 UTC

Did some more testing, where I would mark a message unread in the web client,
read it with Modest, then refresh the web client to see if it is considered
read or unread.

REPRODUCIBILITY:
Seems to work on WiFi, but not to work on 2.5G (EDGE) GPRS.

OTHER COMMENTS:
The e-mail is very short. I open the e-mail for less than three seconds, then
proceed to exit Modest by hitting backarrows and X.

Comment 48 Andre Klapper 2010-03-01 21:13:48 UTC

qole: So there won't be progress here as this cannot be reproduced. :-/
Providing a test account probably does not make sense either as it's GMail...

Comment 49 Alan Bruce 2010-03-04 00:37:16 UTC

It is truly frustrating. I get this problem about 25% of the time, and I'm
still not sure what is triggering it. Sometimes all my mail isn't marked read
in the web client when I read it in Modest on GPRS, sometimes it isn't marked
read when I read it on WiFi (happened again this morning). I hope to figure out
the magic key at some point...

(In reply to comment #48)
> qole: So there won't be progress here as this cannot be reproduced. :-/

An answer to comment 39 would be helpful (need a reverse-moreinfo flag ;-) ) so
at least we can tell what is expected behaviour and what is a bug.

As far as I can tell the flags update happens when going back to the folder
list and during a send&receive.  Flags also seem to be updated immediately when
a message is read via the new message notification which is inconsistent and
therefore confusing.  Anything else?

(In reply to comment #50)
> (In reply to comment #48)
> > qole: So there won't be progress here as this cannot be reproduced. :-/
> 
> An answer to comment 39 would be helpful (need a reverse-moreinfo flag ;-) ) so
> at least we can tell what is expected behaviour and what is a bug.
> 
> As far as I can tell the flags update happens when going back to the folder
> list and during a send&receive.  Flags also seem to be updated immediately when
> a message is read via the new message notification which is inconsistent and
> therefore confusing.  Anything else?

Why do you say is incosistent? We need to update message flags when a message
is opened from a new message notification because in that case there is no
headers window opened and thus flags update won't happen.

I'm starting to think that it's some kind of issue related to network timings
as reporters say that it only happens with GPRS

(In reply to comment #51)
> Why do you say is incosistent?

The result is that some messages are updated as soon as they are read and some
later.  It's probably not intuitively obvious to most users which conditions
cause which behaviour.

> We need to update message flags when a message
> is opened from a new message notification because in that case there is no
> headers window opened and thus flags update won't happen.

I understand that, but it's not obvious to the users.

> I'm starting to think that it's some kind of issue related to network timings
> as reporters say that it only happens with GPRS

Comment 49 says it also happens on WiFi connections :-(

Completely untested speculation: is it possible that a connection switch can
trigger this (eg if an IMAP session is terminated before modest has pushed the
updates to the server)?

yes its on wifi also and it is only updating if I leave the folder (which I
dont want to do as often as I should, some mailboxes I read twice a week when I
find time...), it should update with closing the email read, within mutt I have
to press $ to get this update done but there I am used to do that, within a gui
client I dont want to press send&receive everytime I change something... it
also looks like taking very long to do a send&receive compared to my
"update-folder" in mutt. It should update folders itself, maybe based on
connection type or at least configurable, more often with wifi connection than
with GSM but it should update without need for leaving the folder. I currently
dont use the client but for reading urgent stuff or for testing issues like
this as it still has nothing to do with 'mail-management' for me, for quickly
reading some mails and reply to ok, but I receive about 80 mails which need to
be read in threaded view to keep track of things (and that's only my private
account btw), having no threaded sort function and not properly updated flags
makes it even more painful.

(In reply to comment #53)
> yes its on wifi also and it is only updating if I leave the folder (which I
> dont want to do as often as I should, some mailboxes I read twice a week when I
> find time...), it should update with closing the email read, within mutt I have
> to press $ to get this update done but there I am used to do that, within a gui
> client I dont want to press send&receive everytime I change something... it
> also looks like taking very long to do a send&receive compared to my
> "update-folder" in mutt. It should update folders itself, maybe based on
> connection type or at least configurable, more often with wifi connection than
> with GSM but it should update without need for leaving the folder. I currently
> dont use the client but for reading urgent stuff or for testing issues like
> this as it still has nothing to do with 'mail-management' for me, for quickly
> reading some mails and reply to ok, but I receive about 80 mails which need to
> be read in threaded view to keep track of things (and that's only my private
> account btw), having no threaded sort function and not properly updated flags
> makes it even more painful.

Ok guys don't mix up things. It has been told many times than in normal
conditions those flags are only updated when you *close* the messages view
window. We update them in a bunch. So if you open a message and you close it,
the flags are not inmediately updated, they're only updated when you leave the
folder. I don't see any reason to update them everytime you close a message,
it's a total waste of bandwith and money in GPRS/3G connections.

BTW Lucas I agree that might be it could be inconsistent for an advanced user
that opens an email and inmediately checks in their PCs the status of their
messages, although I don't see 99% of people doing that.

> yes its on wifi also and it is only updating if I leave the folder

does mean that most of the time only leaving the folder or hitting on
send&receive does update, it does also mean that it sometimes just does not
update properly even if folder was left.
I started to follow this bug and vote for it because it didnt update at all.
I only recognized it because I was reading about 25emails on the go and found
them 3h later still unread undeleted in my inbox.
maybe this has to do with loosing connection for a few minutes but so I wasnt
able to update as it was disconnected when I actually performed some action
which would trigger folder update. (honestly I cant remember the exact case but
it was something like.)

the not bug related part:
updating flags isnt that a data intense action and if I read emails otg it
should be clear that reading emails drains your dataplan if volume based.
People do SIP calls and skype calls over GSM connection so why care about a few
kb for updating a mailbox when closing an email (some people may like to
download the email to read and close their internet connection, so it should be
done before connection is canceled), thats not the best way I know.

sorry for interrupting.

Comment 56 Andre Klapper 2010-06-07 11:03:33 UTC

Does somebody still run into this problem withy 10.2010.19-1?

Comment 57 Alan Bruce 2010-06-16 09:27:46 UTC

I'm still getting it occasionally, and not predictably. I really think the
behavior should be changed. Maybe it is how I'm closing Modest. What happens if
Modest is closed when it is minimized on the dashboard? Does it update the read
flags before closing?