Marking non-selected IMAP folder as read doesn't always work

Bug #90824 reported by kko on 2007-03-09
2
Affects Status Importance Assigned to Milestone
Mozilla Thunderbird
Confirmed
Low
thunderbird (Ubuntu)
Low
Mozilla Bugs

Bug Description

Binary package hint: mozilla-thunderbird

This bug is easiest to observe if you have chosen your spam filter to move spam to another IMAP folder.

To reproduce:
- Start TB, and hope you have spam. :-)
- Watch an e-mail get moved to Spam.
- Right-click on the IMAP folder "Spam" and choose "Mark folder as read".
- Repeat last step, because it doesn't work the first time.

I found a 3 years old report about this in the Mozilla bug tracker, which is hardly encouraging, yet this is an annoying little bug that I hope someone can patch.

I show this behavior as well. In my case, it appears to apply only to IMAP folders.

-----------------------------------------------------------
Steps to Reproduce:
1. Receive a new message that is filtered (still as NEW) into an IMAP folder.
2. Open a different folder from the one containing the new message.
3. Right-click the folder containing the new message and select "Mark Folder Read"

Actual Results:
Folder is unchanged; all NEW messages inside are still NEW.

Expected Results:
All NEW messages within the folder are marked READ.
-----------------------------------------------------------

This is on Thunderbird version 1.0 (20041206) / WinXP SP2. I also tested
filtering a NEW message to a subfolder of "Local Folders". While browsing my
IMAP account, I could right-click the local folder and successfully mark it as
read; appears to be IMAP-only.

I also could reproduce the same behavior only for IMAP folder. When a new
message is moved to the specified folder by filter, it is not recognized until
the folder is clicked and refreshed.

The function nsMsgDatabase::MarkAllRead() seems related to this behavior. When
message is just moved and the folder is not refreshed, enumerator (hdrs) skips
new messages.

(in nsImapMailFolder.cpp)
NS_IMETHODIMP nsImapMailFolder::MarkAllMessagesRead(void)
{
...
    rv = mDatabase->MarkAllRead(&thoseMarked);
...
}

(in nsmsgdatabase.cpp)
NS_IMETHODIMP nsMsgDatabase::MarkAllRead(nsMsgKeyArray *thoseMarked)
{
  nsresult rv;
  nsMsgHdr *pHeader;

  nsCOMPtr <nsISimpleEnumerator> hdrs;
  rv = EnumerateMessages(getter_AddRefs(hdrs));
  if (NS_FAILED(rv))
    return rv;
  PRBool hasMore = PR_FALSE;

  while (NS_SUCCEEDED(rv = hdrs->HasMoreElements(&hasMore)) && (hasMore ==
PR_TRUE))
  {
    rv = hdrs->GetNext((nsISupports**)&pHeader);
    NS_ASSERTION(NS_SUCCEEDED(rv), "nsMsgDBEnumerator broken");
    if (NS_FAILED(rv))
      break;

    PRBool isRead;
    IsHeaderRead(pHeader, &isRead);

    if (!isRead)
    {
      if (thoseMarked)
      {
        nsMsgKey key;
        (void)pHeader->GetMessageKey(&key);
        thoseMarked->Add(key);
      }
      rv = MarkHdrRead(pHeader, PR_TRUE, nsnull); // ### dmb - blow off error?
    }
    NS_RELEASE(pHeader);
  }
...
}

I can reproduce the problem under Win XP with TB 1.0.6. with LOCAL folders.

Confirming, for IMAP folders (local folders are ok). Using linux tb build 1.0+
(20050826). Annoying...

I see this bug also, but I've noticed that with my setup, I filter mail with procmail on the server and use IMAPS to acces my mail. If I right-click on a folder other that the current one and select "Mark Folder Read" - nothing happens. However, if I right-click on the folder a second time and select "Mark Folder Read" the messages are actually marked read.

This happens in Thunderbird version 1.5 (20051201)

right, we only mark read the headers we know about, w/o downloading headers we don't have first. Taking...

changing summary to reflect actual problem.

A more common case...

What Happened:
  I selected two or more NEW messages in a non-trash folder and press
  Delete. I then right click on Trash and select "Mark Folder Read".
  The folder blinks read for a second, then goes back to being unread.

What I expected:
  If I throw something away and then try to mark the trash folder
  read, then it should happen.

Notes:
  Given comment #6, I would suggest that when a message is
  copied from one folder to another that the header is either:
  immediately reread OR it is copied with the email. I don't know
  enough about IMAP or whatever to know if that's reasonable or not.

  I supposed that there could be problems with, for example, copying
  5000 emails.

  I also wonder what the user expects. If they see a folder with
  unread messages and they don't *visit* the folder and want to mark
  it read, then shouldn't it be marked read?

  Perhaps there is a better way to show the user that there are
  messages they could not have seen vs. message they haven't read.

  For example:
    Folder foo has 2 unread messages. I click on foo and see the
    subject lines of the messages. I then click on INBOX. A new
    message arrives in folder foo. It has 1 unseen message and 3
    unread messages.

    Perhaps color could denote this:
      If all messages are seen and read: black, normal font-weight
      If unseen messages exist: purple, bold
      If all messages are seen, but some are unread: blue, bold

    Sort of like default web links.

Ciao!

(In reply to comment #8)
> Notes:
> Given comment #6, I would suggest that when a message is
> copied from one folder to another that the header is either:
> immediately reread OR it is copied with the email. I don't know
> enough about IMAP or whatever to know if that's reasonable or not.

Marking a header as "read" when copied is absolutely the wrong thing to do. And isn't the header already copied as-is with the message? I think the problem you described has more to do with deleting (moving to trash) multiple messages that haven't actually been read -- marking/moving as deleting is not the same thing as reading. Perhaps you want deleted messages marked "read" at the same time? Either way, copying isn't the problem; for instance, my deleted messages get marked as "deleted" and not moved to a "Trash" folder.

> I also wonder what the user expects. If they see a folder with
> unread messages and they don't *visit* the folder and want to mark
> it read, then shouldn't it be marked read?

Yes, that's the fundamental problem from the user perspective, as indicated in the initial report.

> Perhaps there is a better way to show the user that there are
> messages they could not have seen vs. message they haven't read.

{snip}

> Perhaps color could denote this:
> If all messages are seen and read: black, normal font-weight
> If unseen messages exist: purple, bold
> If all messages are seen, but some are unread: blue, bold

Color shouldn't be the only indicator used for status, for accessibility reasons. IIRC, Thunderbird already does this (at least with the INBOX) -- I see a red asterisk appear on the folder icon when new messages have arrived, it only turns bold w/ an unread count when there are unread messages -- regardless if they're new or not. I see this most often when junk mail arrives; I have the junk mail filter mark the junk as read so I see the asterisk (new mail) but no unread messages.

(In reply to comment #9)
> (In reply to comment #8)
> > Notes:
> > Given comment #6, I would suggest that when a message is
> > copied from one folder to another that the header is either:
> > immediately reread OR it is copied with the email. I don't know
> > enough about IMAP or whatever to know if that's reasonable or not.
>
> Marking a header as "read" when copied is absolutely the wrong thing
> to do. And isn't the header already copied as-is with the message?
> I think the problem you described has more to do with deleting
> (moving to trash) multiple messages that haven't actually been read
> -- marking/moving as deleting is not the same thing as reading.
> Perhaps you want deleted messages marked "read" at the same time?
> Either way, copying isn't the problem; for instance, my deleted
> messages get marked as "deleted" and not moved to a "Trash" folder.

When I'm talking about "reread" in my message, I mean the header is
reread from the mail server, not that the message is marked "read". I
apologize for not being clear.

Let my again:

Given comment #6, I would suggest that when a message is copied from
one folder to another that either:
 1) The header is read again from the mail server
 or
 2) The cached header is passed to the new folder so it doesn't have
    to be read again from the mail server.
 I don't know enough about IMAP or other mail stores to know if option
 2 is reasonable or not.

I hope that rewrite helps and sorry about re-using read in two
different ways. :-)

Ciao!

kko (kko) wrote :

Binary package hint: mozilla-thunderbird

This bug is easiest to observe if you have chosen your spam filter to move spam to another IMAP folder.

To reproduce:
- Start TB, and hope you have spam. :-)
- Watch an e-mail get moved to Spam.
- Right-click on the IMAP folder "Spam" and choose "Mark folder as read".
- Repeat last step, because it doesn't work the first time.

I found a 3 years old report about this in the Mozilla bug tracker, which is hardly encouraging, yet this is an annoying little bug that I hope someone can patch.

kko (kko) wrote :

Oh, this is on TB 1.5.0.10.

Changed in thunderbird:
status: Unknown → In Progress
Changed in mozilla-thunderbird:
assignee: nobody → mozilla-bugs
status: Unconfirmed → Needs Info
Changed in mozilla-thunderbird:
importance: Undecided → Medium

This issue is still ongoing in 2.0.0.12 and IMAP.
One update on it though. If you 'mark folder read' twice, it works.
The first time you do it, it temporarily marks the folder as read, and then the unread count on the folder goes back up to what it was as it downloads all the message headers for that folder. After that if you 'mark folder read' again, it will work.

The 'mark folder read' feature should download message headers and *then* mark them as read, not mark them as read then download message headers.

kko (kko) wrote :

Why was the status Incomplete? Changing to New, since I can't confirm my own bugs.

Still occurs with version 2.0.0.16 (20080724), Hardy.

Changed in mozilla-thunderbird:
status: Incomplete → New
kko (kko) wrote :

This is still an issue. It surprises me if other people aren't irked by this misbehaviour in Thunderbird. Either they're bothered by something else instead, or they're just using T-bird differently so they don't face this bug, or they're not using T-bird at all.

Would be nice if someone could confirm the report here.

Daniel T Chen (crimsun) wrote :

I can reproduce this symptom in 8.04 and 8.10. However, I cannot reproduce this behaviour using TB 3.0 in Fabien Tassin's ppa.

Changed in mozilla-thunderbird:
importance: Medium → Undecided
status: New → Confirmed

WFM with current trunk build - so you will see this fixed in version 3, but not versoin 2. Don't know what fixed it. see bug 400317

Changed in thunderbird:
status: In Progress → Invalid

No, this is still here.
Have a server side filter move junk to the junk folder, try to mark the junk folder read before you've entered it the same session - it will never work.

Actually, those are not completely correct steps.

It's thunderbird's junk filter that move spam to the Junk folder. A the Junk folder marked is not marked for offline use.

hmm, so my headers must have been downloaded

Changed in thunderbird:
status: Invalid → Confirmed
Changed in thunderbird:
importance: Unknown → Low

I have this issue too I believe. I have the option to check all folders for new messages enabled, and server side filtering. Often a folder gets some messages and is bold (no "new" icon). Then I select mark folder read and the "new" icon appears, but the number of unread folders doesn't change. If I select mark folder read again, then it works.

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

Mathew Hodson (mhodson) on 2018-08-14
affects: mozilla-thunderbird (Ubuntu) → thunderbird (Ubuntu)
Changed in thunderbird (Ubuntu):
importance: Undecided → Low
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.