Open Bug 1545955 Opened 6 years ago Updated 1 month ago

When using filters, bold blue font for new message is set on the wrong account

Categories

(Thunderbird :: Folder and Message Lists, defect)

defect

Tracking

(Not tracked)

People

(Reporter: rover.bugfinder, Unassigned)

References

Details

(Keywords: ux-trust)

Attachments

(5 files)

Attached file new-msg-indicators.zip

User Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3) Gecko/20170401 Firefox/56.0

Steps to reproduce:

Have two POP3 mailboxes configured in Thunderbird. Make a filter that would automatically move messages from mailbox 1 to mailbox 2 (in my case: forward mailbox 2 to mailbox 1 server-side and split messages between the two accounts on client-side, in Thunderbird, basing on the "To:" header). Receive a message by mailbox 1 that will be moved to mailbox 2 by the filter.

Actual results:

When all the received messages are moved from mailbox 1's Inbox to mailbox 2's Inbox by the filter, mailbox 2's Inbox gets marked with the new message indicator (blue font), but:

  • the mailbox 2's name stays in BLACK font (should probably become blue, just like its Inbox),
  • the mailbox 1's name stays in BLUE font (should be black, because it has no new messages),
  • the mailbox 1's name turns black (as it should) when you enter mailbox 1's Inbox (which has NO undread mail, so should have been black from the beginning).

Expected results:

When all the received messages are moved from mailbox 1's Inbox to mailbox 2's Inbox by the filter, it's the mailbox 2's Inbox and name that should have been marked with the new message indicator (blue font).

Present in version 60.6.1, defect present in a bunch of previous versions also.

Defect reproducible each time, also in safe mode (in other words, no add-on is causing the defect).

Additionally, the blue font on mailbox 2's Inbox disappears after restart. This may be another bug, but this may equally well be a feature (closing the program means all mail was acknowledged and no new mail was received after restart, so no reason for blue font).

This is a cosmetic issue, but it may be confusing to users.
The defect is a bit similar to the following defects or various parts of them:

See the attachment:

  • new-msg-indicator-wrong-box.png - describes the issue (the word "Odebrane" means "received" and I guess it's called "Inbox" in english),
  • no-new-msg-indicator-after-restart.png - status after Thunderbird restart.

Hmm, that seems to be problem area. Looks like your bug here is very similar to bug 632372.

See Also: → 632372

Indeed it is and it's one of the bugs I've found and put on my list (however, I don't know how to make a "nice" bug link like you did).
Anyway, you can treat this as a "re-confirmation": the bug existed in v. 3.1.7, in v. 60 and today I finally managed to check v. 68.2.1 and it's present there as well.

Seems to be partially fixed in 68.2.2, I don't know if by accident or not. The blue marker doesn't show in the "wrong" account at all right now, but it doesn't show in the "right" account either.
"Wrong account" means the account receiving the mails and moving them to other accounts' folders with filters ("mailbox 1").
"Right account" means the target account ("mailbox 2").

Just to let you know, the problem still persists in Thunderbird version 68.3.1. If anything was indeed fixed last time, it got broken again. If not, that may have been some coincidence or another sub-part of the same problem.

This bug has seen no action, hence nothing was fixed. I see this annoying bug on a daily basis. I have an account that receives bugmail and then immediately moves all messages to a local folder. So the account doesn't really have any new messages, but it still shows in blue. As soon as I click onto an empty folder "xx" in the account, the blue goes away.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [dupme?]

I can't reproduce the "new mail" star on the wrong folder issue (comment #5) any more in TB 78 and TB 91. Can this bug be closed along with some/all of the ones listed in comment #0?

The bug is still there, but it has morphed. Like in comment #5, "server folder" still changes to blue when new mail passes through that server which is later filtered to a different folder. These days the fact that all server folders are blue papers over the issue, but you can still see it if you put

#folderTree {
  --primary: red !important;
}

into your userChrome.css. The yellow biff start/circle is no longer there though.

I can't tell about the other defects, but this one is still present in 78.14.0, checked recently. Sorry.

Keywords: ux-trust
Summary: When using filters, blue font for new message is set on the wrong account → When using filters, bold blue font for new message is set on the wrong account
Whiteboard: [dupme?] → [dupme]
Severity: normal → S3

Cannot reproduce this bug with TB 115.2.3 (64-bit) on Windows using IMAP accounts. I tried hard by utilizing filters to move new messages automatically to sub-folders and lokal folders.

Thanks Thilo.

Reporter, does this still reproduce for you with version 115?

Flags: needinfo?(rover.bugfinder)
Whiteboard: [dupme] → [closeme 2023-10-01]

Hi.
Sorry, the defect still exists in 115.3.0 :(.
POP3 account that "Get messages" was clicked on and which indeed received the messages: blue font (new message marker) on account name (but no new messages), no blue font on folders (correct, I guess, because there are no new messages inside).
POP3 account that the messages received were moved to by filters - blue font on "Inbox" - I suppose it's correct, because the received messages were moved there and are still new and unread. Black (the default) font on account name, even though there are new messages in subfolders.
Will attach a new screenshot right away.

Easier test: no need to forward server-side:

  • create a message filter that moves messages from account 1 to account 2 (both POP3, downloaded) if account 2's e-mail is in "To",
  • send yourself an e-mail to both account 1 and account 2 in the "To" line,
  • get messages for account 1.
Flags: needinfo?(rover.bugfinder)

Defect proof in v115.3.0 attached - tb-115.3.0-wrong-box-highlighted-scr.png.

Whiteboard: [closeme 2023-10-01]
See Also: → 1836511
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: