Closed
Bug 545193
Opened 15 years ago
Closed 13 years ago
IMAP - New message indicator disappears after viewing one new message
Categories
(Thunderbird :: Folder and Message Lists, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 596190
People
(Reporter: nbaldridge, Unassigned)
Details
(Whiteboard: [closeme 2011-09-08])
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.2pre) Gecko/20100205 Ubuntu/9.10 (karmic) Firefox/3.5.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1
A user receives many messages at once, but leaves everything in the Inbox marked as unread until it is dealt with.
He prefers to have the new message indicator stay active beside each message until the message is viewed.
Currently, the new message indicator in Thunderbird 3 disappears beside each message as soon as one new message is viewed and closed.
The issue isn't knowing that there are new messages in a folder - it's which messages are new.
I've explained to the user that this workflow is counter-productive - user the read state to determine the 'newness' of a message - but he would much prefer if the new message indicator stayed beside each new, untouched message received.
Switching between folders would clear the new message indicators, but receiving new batches of messages, opening (and closing) messages would not cause the indicator to disappear.
This is a changed behavior from Thunderbird 2.
Reproducible: Always
Steps to Reproduce:
1. Receive several messages
2. Open a single message
3. Close message
Actual Results:
New message indicator disappears for all additional messages
Expected Results:
New message indicator stays except for message viewed.
Comment 1•15 years ago
|
||
Works for me on Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b2pre Thunderbird/3.0.1 ID:20100111101938 -- can you have the user retry in Safe Mode (http://kb.mozillazine.org/Safe_Mode)?
OS: All → Windows XP
Reporter | ||
Comment 2•15 years ago
|
||
Perhaps this is misunderstood - this happens on Windows XP and Linux for certain.
1) Receive multiple messages
2) Open one of the group of newly received messages
3) Close message you are viewing
4) All new messages lose their new message indicator (the starburst).
This happens in safe mode as well as regular on both XP and Linux.
The intended (or expected) behavior is that the new message indicator stays lit beside each new message, until viewed for the first time.
This is not regarding the read or unread status.
Reporter | ||
Comment 3•15 years ago
|
||
Ah - this doesn't occur when using the preview pane, but this user either opens messages in tabs or in separate windows.
Comment 4•15 years ago
|
||
I still can't reproduce; the per-message New highlights remain until the messages are marked read (and usually return if the messages are marked unread again). Tried opening messages in new tab and in new window.
Reporter | ||
Comment 5•15 years ago
|
||
As I mentioned, this happens for our organization with IMAP accounts on both 3.0.1 Windows XP and Linux nightly builds.
If you receive a batch of new messages, open one of them in a new tab or a new window.
Next, close the window or tab that just opened after having switched focus, or changing to that tab.
The other messages in the batch that would normally keep their new status lose the new status.
It happens every time when using this method, and does not happen when viewing the messages via the preview pane.
Comment 6•15 years ago
|
||
Nicholas, does this happen in v3.0.3?
Reporter | ||
Comment 7•15 years ago
|
||
Yes, it does.
Comment 9•13 years ago
|
||
RESOLVED INCOMPLETE due to lack of response to previous question. If you feel this change was made in error, please respond to this bug with your reasons why.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → INCOMPLETE
Updated•6 years ago
|
Resolution: INCOMPLETE → DUPLICATE
Comment 11•6 years ago
|
||
readadjusting
You need to log in
before you can comment on or make changes to this bug.
Description
•