347150 - "Mark As Read" Right Click Menu Bug

Status: RESOLVED DUPLICATE of bug 257885

(Thunderbird :: Mail Window Front End, defect)

Description

[Buford T. Justice]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4

When selecting a message on my message list that has been read, I can right-click on the message and go to MARK > AS READ which is sometimes checked or unchecked regardless if the message has been read or unread.  I would think if the check is in front of AS READ then the message is shown as being read.  However, I can click on a message and sometimes the check is not there for a read message.  If I click on it so that a check is in front of AS READ, the message is shown as unread.

Reproducible: Sometimes

Steps to Reproduce:
1.  Left-click on a message on your message list so it is highlighted in blue.
2.  Right-click once on the same selected message.
3.  Go to MARK > AS READ.  Sometimes the check is there and sometimes it is not.



Expected Results:  
If the message has been read then there should be a check mark in front of AS READ.  If the message is unread then there should not be a check mark in front of AS READ.

Comment 1

[Buford T. Justice]

For some reason, the USER AGENT and BUILD windows picked up my Firefox instead of my Thunderbird.  This bug is about the Thunderbird 1.5.0.5 version.

Comment 2

[Jo Hermans]

this is Seamonkey bug 64326, but I can't find a Thunderbird bug that describes it. Bug 223073 mentions it, but is a bit different.

Comment 3

[Buford T. Justice]

Both of those bugs are old.  Bug 64326 was reported back in 2001 and Bug 223073 was reported back in 2003.

Anyway, if you select some message regardless if they are read or unread, when you MARK > AS READ they should all be marked as read and have the check mark.  Or if you select a bunch of read messages, it should remove the check mark from MARK > AS READ.  Or if you select a bunch unread messages, it should add the check mark to MARK > AS READ.

Perhaps there should be a MARK > AS UNREAD option instead of using the check mark option with MARK > AS READ.  That would probably be better if the user selects both read and unread messages and wants to mark them all as read or unread.

Comment 4

[Mike Cowperthwaite]

(In reply to comment #3)
> Both of those bugs are old.  Bug 64326 was reported back in 2001 and 
> Bug 223073 was reported back in 2003.

So?  There are many old bugs that haven't yet been solved, some of which have dozens of dupes ranging from the month after to just last week.

I don't see a useful distinction between the behaviors in 223073 and in 64326, other than the platform on which they exist.  I'd dupe this to 223073.  I'm not sure, but I doubt this is a Core bug, altho the patch could probably be ported between the two.


> Perhaps there should be a MARK > AS UNREAD option instead of using the check
> mark option with MARK > AS READ.  That would probably be better if the user
> selects both read and unread messages and wants to mark them all as read or
> unread.

This is an excellent avenue to pursue.  The main part of the context menu changes considerably when multiple messages are selected; it makes sense to change the Mark submenu in that case as well -- providing only items for 
As Read, As Unread, Add Flag (Star), Remove Flag (Star), As Junk, As Not Junk.

I would do this such that none were checked, but if all the selection shared 
the Read/Unread, Flagged/Unflagged or Junk/Not Junk status, the corresponding item could be disabled in the menu.

Comment 5

[Mike Cowperthwaite]

(In reply to comment #4)
> I'd dupe this to 223073.  

Duh -- I should have read this bug more carefully.  Both of those other bugs are based on the problem where multiple messages selected with differing states.

This bug is about the problem with a single selection showing the checkmark with the status of the *previous* message, if that message's Read state was changed.  And there seems to be some interest in fixing this, at the dupe.