Maybe I'm missing something about how this is supposed to work. I select a group of messages and now I want to mark them as read. I go to Mark->As read. Now sometimes there is a check box there, and sometimes there isn't. When its not there, it'll mark my messages as read. If it is there, it only removes the checkbox. Seems to me this menu option should just do what I'm asking and not have a "state." Am I missing something about the intent of menu item?
Well, this is a feature, not a bug. If you select a *read* mail and do Mark>Read it's checked, because the mail is already marked read. If you select the menu again, it'll do the reverse and select the mail in question as unread and thus remove the checkmark. The latter worksforme in 2001010404
I have to agree with the Reporter here. I think this is kinda confusing, especially if some of your messages are Read and some are not that you are selecting. I think the solution is to have Mark as Read do just that mark something as Read and another Menu Item to 'Mark It Unread' thus it would alleviate this confusion. Marking NEW to see what the higher ups think
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Check mark next to Mark->"As Read". Why? → 'Mark as Read' changes status of Read Messages
Ok, I understand what was going on before, but I think the second suggestion is better and less confusing. For instance, what state is the check-mark in if some of the selected messages are read and others are unread?
have you tested it? [imo, and my opinion matters because this might be my implementation that you're staring at] the correct behavior is to only indicate read if all messages are read. This is of course the case after you click on it in the unread state. yes clicking on it when in the read state should make them unread. but i haven't used mozmail in a while...
Actually I was asking a rhetorical question. Asking as a naive user might "Hmmm, what happens if I select some messages that are read and some aren't? What would I *expect* the checkbox state to be?" Sorry. I just tested it with the month-old build I use at home. I selected 6 messages. Messages 1 and 6 were read. I did this by clicking on the first message (which makes it read) and shift-clicking on the 6th message. Then I went to the menu intending to mark the whole range of messages "read." The checkmark was present, so first I have to select "Mark Read" which makes all six messages *unread*. Then I have to go to the menu and choose "Mark Read" again which makes all the messages *read*. So I guess I think the 12-05 build doesn't work as you describe. This is non-intuitive for several reasons: 1) I almost never want to mark a news message I've read as unread. I mark them read so that I can tell where I'm caught up to. I would assume others use it for the same purpose, but who knows. Mail is slightly different, but I still never need to mark things unread. 2) The menu says "Mark as read" not "toggle read status" 3) With things selected it can be difficult to tell the difference between read and unread (I don't use the little green lights, just bold/normal). You can't unselect to see the status, or you have to do the two-step process again. I think separate "Mark as Read" and "Mark as Unread" is the way to go, and then these two choices don't care what the initial state of the message is. My 2 cents.
I noticed that in 4.x, we had mark "as read" and "flag". neither toggled, both always marked messages read or flagged, no matter what the current state. that goes to support what Eric said: > almost never want to mark a news message I've read as unread. I'd be happy to go either way on this one: 1) make it so it always says "mark as read" and always marks as read or 2) toggle it between "mark as read" and "mark as unread" (and "flag" and "unflag") jglick / mpt, comments? as soon as we all decide, I'll go make the fix.
Status: NEW → ASSIGNED
4.x has it right. `Mark as Read' and `Mark as Unread' are two different commands, which should have two different menu items. You can't have just one item, because if I select multiple messages/folders which contain some read and some unread items, you can't know whether I want to mark them all read or mark them all unread. They're commands, not attributes (that's why they have a verb in their name), so neither of them should have checkmarks.
I'd be happy to have us get rid of the checkmark and have 2 menu items in all places where this occurs. The same for flagged. Or at least change the text rather than put the checkmark. I can't remember what algorithm I used to determine whether or not the action was going to be unread or read when there was a mixture of the two in the selection.
I definitely prefer the two menu items always present solution. It seems to me there is no "right" algorithm for the case when there is a mixture of read/unread or flagged/unflagged.
more menus don't solve behavior problems. We have <key>[m] and <key>[f] (or however you flag messages) and they need a behavior too. you can't just say ShiftM marks Unread and M marks read, and ShiftF unflags and F flags. As such, our behavior should match 2001-01-04 19:22. And F and M should map to the menus.
4.x has `Flag Message[s]' and `Unflag Message[s]' as two separate items too.
I don't see the point of marking a read message unread? I think we should mark all select messages read, or if all message already are read we should disable the menuitem.
The reason to mark as unread is that flagging sucks. I mark messages as unread when I need to revisit them. The only easy way i've found to revist messages is to use the keys to go to the next unread message. Flagging is really a sorting feature which doesn't help me when i'm trying to go from message to message w/ the keyboard.
Then we should enhance flagging to be better! The original idea of flagging is the use you use unread for, timeless.
Being able to mark messages as unread is a basic example of the idea that the user should be able to undo actions. I frequently mark messages as unread after I mark a message read by mistake, or when I delete a message and 4.x automatically goes to the next one (marking it unread) but I don't have time to read it right now.
Okay, if this feature really is useful, as mpt claims then I agree that we should have two separate menu items (Mark as read, Mark as unread).
I agree, two menu items will help make these features more clear. Mark --> As Read As Unread --------- Add Flag Remove Flag Wording ok?
please spec out the behaviors for everything before changing this. Does m still toggle or does it only mark as read? how does one navigate flagged messages? How does flagging behave. Assume I select a mixture of read, unread messages and flagged and unflagged. Then explain how you hint about the key shortcuts for M and whatever flagging is. Full Spec before leaping.
`Mark' submenu should include the following: * `as _Read': Marks all messages in the selection as read. * `_Thread as Read': Marks all messages, in the threads which contain the selected messages, as read. Is not available if the current selection is one or more folders or accounts. * `as _Unread': Marks all messages in the selection as unread. * [Separator] * `as _Flagged': Flags all messages in the selection. Is not available if the current selection is one or more folders or accounts. * `as Unfla_gged': Removes flags from all messages in the selection. Is not available if the current selection is one or more folders or accounts. `Go' menu should contain (amongst other things) the following: * `First _Unread Message': navigates to the first unread message in the selected account, or (if no accounts are selected) in the selected folder or folders. Is not available if no folders/accounts are selected. * `_Next Unread Message': navigates to the next unread message in the selected etc etc etc. * [Separator] * `First _Flagged Message': navigates to the first flagged message in the selected etc etc etc. * `Next Fla_gged Message': navigates to the next flagged message in the selected etc etc etc. As for keyboard shortcuts for any of the above, I have no idea yet (4.x's shortcuts weren't i18n-friendly). That do?
OS: Linux → All
Hardware: PC → All
*** Bug 64772 has been marked as a duplicate of this bug. ***
$0.02: I appreciate that the 'm' key toggles. I navigate the mail/news window with the keyboard, usually, and often get focus in the wrong pane, so I press Page Down intending to scroll the message, and instead scroll to a new message and it gets marked read. I press 'm' to undo my mistake, scroll back to the message I was really reading, and TAB into it. I think it's fine if Mark Unread is a separate action, so long as there is a reasonable keyboard shortcut for it. 'm' seems convenient enough as a toggle, but clearly some people are confused by it.
The idea of a separate "Mark as Unread" menu item was WontFix'd at bug 124531 with no discussion. That's probably too abrupt for the committee, but I'm basically in agreement with it. For the single-item case, the current behavior is not broken (mostly; there is bug 257885). I think the "as Read" is an unfortunate phrase (in English, anyway) made necessary by the fact that "read" is an adjective here but is also a verb with a different pronunciation. In my mental model, "Read" is the name of the mark, rather than an adjective; it's not much different from a tag. Similarly, I'd change the "Add Star" (or "Add Flag") to "With Star/Flag". For the multiple-selection case: Note that the context menu for messages already changes when there are multiple messages selected. I think the Mark submenu could change in that case as well. From bug 347150 comment 4: > 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. [....] Alternately, from bug 364348 comment 4: > Here's an idea: when multiple items are selected, don't put items in the menu > to directly control the various marks; instead, put an item [...] called > "Marks and tags...", which opens a dialog to control multi-message marking. > I envision this similar to the Attributes checkboxes seen in the Properties > dialog in Windows Explorer when multiple items are selected [....] I think either of these ideas would be an obvious improvement on the context menu. I'm not so sure if the top-level Message menu should also change. (I would like to see an additional change to the Mark menu -- bug 233182 -- but that's not this bug.) Adding dependency on the TB bug for the same issue.
Summary: 'Mark as Read' changes status of Read Messages → 'Mark as Read' changes status of Read messages [multiple items selected]
Heck, the menu item should just say what it's going to do. If it's going to mark the messages unread, then it should say "mark as unread". It should not have a confusing check mark that might mean "this is the current state" or might mean "this is the state that I'm going to apply".
I wish I could "scratch my own itch". Hopefully this is helpful. To define how, as a user, I see things, messages are either "read" or "unread" to me. It seems like a like a flag, but the user interface does actions. And most people, I think non-technical users, don't think in "flip the flag" way. Intuitively, I would perform the action "mark message(s) as read" or "mark message(s) as unread". This is especially true when multiple messages are selected. Unlike the current behavior of "m" or the context-menu (right-click); which does "toggle" the flag. Also, the current behavoir only understands the first message when multiple ones are selected. Also, there is an "All read" context-menu, but no opposite. For logical completeness, as well as intuitive interface, and not confusing old users, I would suggest: 1) Leave "m" and "<checkmark> As Read" as is. 2) Add Shift-"m" as mark all (in selection) read, keep "All read" context menu, and order below #1. 3) Add Shift-"u" as mark all (in selection) unread, add "All unread" context menu, and order below #2. Oh, last comment, I agree with #24. The current checkmark with "As Read" is open for interpretation. Though you do it once and figure it out, it is a bit of a surprise for new users.
Assignee: mail → nobody
QA Contact: laurel → message-display
You need to log in before you can comment on or make changes to this bug.