User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Firebird/0.7 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Firebird/0.7 right click on a list of new mails, I want to mark them as read, but the mark as read remember the choice from last time. Which means the "mark as read" is already selected, then if I select mark as read, there will be no action, just set the mark as read to unselected, I will have to find and click it again. Reproducible: Always Steps to Reproduce: 1. 2. 3.

One workaround: After selecting the group of new messages you want to mark as read, click the read/unread icon on the message(s) that are highlighted and displayed as read. Then, when you attempt to mark selected messages as read, it will work. :) If you're able to highlight a group of messages quick enough, i.e. before thunderbird marks any of them as read, you will not have this problem. If you're too slow, then just one read message (among several that are also highlighted but unread) will cause the mark as read flag to already be set. Iirc, in past builds you had the option of setting the number of seconds before thunderbird marked a message as read. I don't see that option available in this build (20031128). Changing that to a larger number would also be another workaround, as you could highlight all the unread messages before tb marked any of them as read, and consequently, the mark as read option would not already be set for the selected messages.

Thunderbird version 0.6 (20040502), Windows XP Professional SP1 I experience a similar behavior. If I mark a message read, the checkbox sticks. If you right click on an unread message, the "Mark > As Read" option is checked. It should be unchecked to reflect the message's current status. This bug did not exist in Thunderbird 0.5, to my knowledge (I never experienced it). On USENET, this bug is really apparent. Let's say I want to mark a "spam" message as read. I basically have to just click and wait for Thunderbird to load the message and then mark it read automatically. The behavior should be this: Right click, Mark. If the message is read, the As Read checkbox should appear. If the message is not read, the As Read checkbox should not appear.

From the usability point-of-view the mark-as-read option should be implemented as follows: Two options in context menu: mark->as read and mark->as unread (as they are actions, not indicators!). If a message is already marked as read, then the mark->as read option should be greyed out. If a message is unread then mark->as unread should be greyed out.

I'd like to agree with ch.nolte; menus are usually used for actions; having a toggle flag in a menu that both operates on a group of objects and also shows the status of those objects is confusing, especially since it's totally expected that a user might select both read and non-read messages and try to mark all of them as 'read' or 'unread'. I'd also suggest that there should be two key shortcuts for marking as read; or perhaps even three: mark as read, mark as unread, toggle read flag.

I think I've found a related, and also strange, behavior.... Okay, start with two messages - both marked as read. First, select message #1, right click on it, and mark is as unread. Now, right click on message #2 (without selecting it, this is important!) and look at the "As read" selection. Despite the fact that it's the only message you're right clicking, and it is indeed marked read, there will be no checkbox. Mark it read or unread, and the checkbox will still not be there. But, the option does at least work. If the message you're selecting (#1) is READ (not unread), the checkbox works as expected when right clicking message #2. -[Unknown]

It seems that the command and the status select messages differently. Looks like this bug, as well as the related one I mentioned. I'm not so sure how to fix the one I mentioned, but it's apparent here: http://lxr.mozilla.org/aviarybranch/source/mailnews/base/resources/content/mailWindowOverlay.js#651 That only the first message's status is checked to show the toggle. I would urge that it should work like any normal checkbox - three states: off, on, and partial. So, if the selection has some read, some not read (or some flagged, some not flagged, etc.) it should show a "partial" check there. What is a partial check? In this case, a bullet, perhaps. Maybe a lighter checkmark. I'm not a design person. This is compared to the functionality that actually marks the messages read. IT does its job properly both for many messages selected *and* one message selected, another right clicked. As such, I would think its methodology is correct: http://lxr.mozilla.org/aviarybranch/source/mailnews/base/src/nsMsgDBView.cpp#1153 I may try to whip up a patch, but I only started using Mozilla Thunderbird last night, so I still have to get more used to its code. Plus I'm really rusty at C++ (even if this is mostly JavaScript.) But, can anyone confirm that my proposed solution is/might be correct? Hope this was helpful and not just bugspam. Thanks, -[Unknown]

This doesn't seem to be totally perfect itself, but I think it presents a much more logical interface. Essentially, the "read", "flagged", and "junk" status of selected messages is, by this patch, calculated to mean *all* messages. In other words, if one of the messages is not read, it says "not read". This makes more sense to me, considering it's a positive action. If I select 10 messages, 5 read and 5 unread, and I say "mark as read/unread", I *probably* mean mark them all read. Only if they are all read do I *probably* want them all to be unread. This isn't perfect though, and could be benefitted by having two options (as read/as unread) although personally that would feel like clumsy UI. Sorry this isn't against cvs or anything, but I couldn't find what branch/revision my mailWindowOverlay.js came from - so it's just a patch for mozilla/mailnews/base/resources/content/mailWindowOverlay.js. It's probably the same for mail/. But, I'm not sure this fixes it all. The select #1 and right click #2 I described above still seems to happen. So maybe this patch isn't even applicable to this bug. But it does seem to help it. -[Unknown]

It would be _so_ much easier to do it like Evolution: - if everything you have selected is unread, the only option avaliable is "Mark as read" - if everything you have selected is read, the only option avaliable is "Mark unread" - if you have a mix of read and unread, both options should be avaliable

(In reply to comment #8) > It would be _so_ much easier to do it like Evolution: > > - if everything you have selected is unread, the only option avaliable is "Mark > as read" > - if everything you have selected is read, the only option avaliable is "Mark > unread" > - if you have a mix of read and unread, both options should be avaliable Well, that's why I wrote my patch as I did. In fact, originally, I had an "anyAreRead" in there as well... which would give you the three options (allAreRead, anyAreRead, and neither) you speak of. I would agree that simply displaying the relevant option makes good sense even for that, I hadn't thought of that (but having options always there, but sometimes greyed out... I do not personally think is a good plan.) If someone can give me an idea of who to request r/sr from, I can try to do a patch against the trunk that does what you're saying (assuming locale changes are okay.) Though, again, this doesn't seem to solve the underlying issue of the checkmark state. It seems to, at times, not match the result of the SelectedMessagesAreRead() for some reason. I may not be experienced enough with XUL... -[Unknown]

This is basically Seamonkey bug 64326.

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

Thunderbird version 1.5 (20051201) The current behavior is as follows: If a consecutive series of messages is selected, then selecting [Mark > As Read] on the toolbar will set all selected messages to the reverse of the state of the first message in the series. Thus, for example, if you select 10 consecutive messages where the first is already read and then select [Mark > As Read], all the selected messages will be marked unread (reversing the "already read" state of the first message). If this behavior is NOT what this bug is all about, please let me know. I will submit a new bug.

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

(In reply to comment #10) > This is basically Seamonkey bug 64326. > Should we dupe this one to that one, and make bug 64325 a CORE bug?

This doesn't help. First of all for me the "mark as read" option on the toolbar button is always grayed out, no matter whether the selected message is read or unread. I can click the glasses button (instead of the arrow) to do the same thing as if I right clicked and clicked mark as read, but still sometimes I have to click twice, and it's not obvious what clicking the glasses button (instead of going into the menu) is supposed to do before you do it. That's why I've never used it until now. Secondly, the right click menu still behaves in the same **** way as when this bug was submitted 3 1/2 YEARS ago. Finally, you shouldn't have to press "mark as read" to mark something as unread! That just doesn't make sense from a usability perspective. Just get rid of the checkbox and do us all a favor and implement what many others have suggested: "mark as read", "mark as unread", and maybe a toggle read status. It's impossible for that to be unclear, and I can't see how this could be a bad thing to put in. Just because you have less buttons to click doesn't mean your interface is better. (In reply to comment #12) > Thunderbird version 1.5 (20051201) > > The current behavior is as follows: > > If a consecutive series of messages is selected, then selecting [Mark > As > Read] on the toolbar will set all selected messages to the reverse of the state > of the first message in the series. Thus, for example, if you select 10 > consecutive messages where the first is already read and then select [Mark > As > Read], all the selected messages will be marked unread (reversing the "already > read" state of the first message). > > If this behavior is NOT what this bug is all about, please let me know. I will > submit a new bug. >

(In reply to comment #0) > right click on a list of new mails, I want to mark them as read, but the mark > as read remember the choice from last time. This symptom (also mentioned in comment 2 & 5) has been fixed for 2.0 -- bug 257885. Oddly, the poster of comment 5 then added comment 6, talking about something else and morphing the bug; that symptom is Seamonkey bug 64326 and (now) TB bug 364348. (In reply to comment #15) > This doesn't help. You're right: nothing you said is helpful. > First of all for me the "mark as read" option on the toolbar button > is always grayed out, no matter whether the selected message is read or > unread. "Grayed out"? You should open a separate bug for that, but do some testing first -- in particular, be sure you see the symptom after you've disabled all extensions (e.g. run TB in Safe Mode).

(In reply to comment #16) > (In reply to comment #15) > > This doesn't help. > > You're right: nothing you said is helpful. No need to be sarcastic. The post I was replying to essentially asked if the current behavior solved the problem, and I'm just saying that solution doesn't help the original problem. > > First of all for me the "mark as read" option on the toolbar button > > is always grayed out, no matter whether the selected message is read or > > unread. > > "Grayed out"? You should open a separate bug for that, but do some testing > first -- in particular, be sure you see the symptom after you've disabled all > extensions (e.g. run TB in Safe Mode). That was just a side note and wasn't my main point. Since I never use that feature, the fact that it was grayed out didn't bother me and I didn't think to file a bug. And I don't have any extensions. But even if it wasn't grayed out, it looks like it essentially does the same thing as the option in the right click menu. I don't mean to post a useless comment that just agrees with everyone else, but since comment #12 was asking if the current behavior fixed this problem, I thought I would comment that I believe it does not, because I would hate for this to get closed and resolved because someone thought that adding the button fixed the original problem.