Open Bug 327828 Opened 19 years ago Updated 2 years ago

With multiple selected messages "Mark all read" and "Mark thread as read" very unintuitive

Categories

(Thunderbird :: Mail Window Front End, defect)

defect

Tracking

(Not tracked)

People

(Reporter: bart, Unassigned)

References

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1 When multiple messages are selected, the menu items and context menu items "Mark all read" and "Mark thread as read" are unintuitive. When I select "Mark all read" I expect to have all the *selected* items marked read. And the "mark thread as read" action should probably be named mark *threads* (not thread) as read if multiple threads are involved in the selection. It acts that way: it marks all threads of all selected messages as read. Reproducible: Always Steps to Reproduce:
> When multiple messages are selected, the menu items and context menu items > "Mark all read" and "Mark thread as read" are unintuitive. When I select "Mark > all read" I expect to have all the *selected* items marked read. And the "mark > thread as read" action should probably be named mark *threads* (not thread) as > read if multiple threads are involved in the selection. It acts that way: it > marks all threads of all selected messages as read. I'm not sure I agree. Context menues and command menu choices do not generally have detail that gives the menu choice as a "plural" when non-plural is also a possibility. As for your specific examples. "Mark all read" means all, not "all selected". And in fact that's how it works (except in the case of bug 321435). "Mark thread as read" marks every thread read in which you have at least one message selected, as one would expect To mark selected items you select your items and use the context menu mark>as read. Or shortcut "M" or command menu item mark>as read Scott, wontfix?
Severity: normal → trivial
OK, I agree with most of your comments. Still, the context menu item "All read" shouln't really be there then. Context menus apply to selected items by definition, you right click on your selection to do something with that. "Mark>All read" translates to "Mark>All OF THESE read" in my mind. It's very unexpected that while all of the Mark commands apply only to the selected items, this one doesn't. In fact, it's the ONLY item in the context menu that applies to more than just the selected items.
wontfix comment 2, removing "mark, all read" from context menu? (i haven't checked but other aspects of this may be covered in other bugs)
Assignee: mscott → nobody
Component: General → Mail Window Front End
QA Contact: general → front-end
I'm a bit torn... in one way it's confusing - especially "mark thread as read" when you aren't even in threaded mode. Shouldn't be to hard fix if we want to. InitMessageMark() http://lxr.mozilla.org/seamonkey/source/mail/base/content/mailWindowOverlay.js#786
Wayne: did you have a reason for wanting "mark all read" in the context menu when multiple msgs are selected?
Curious ... Was mark all read on the file menu in netscape? Maybe it wasn't even on the context menu. Short answer no. It is a folder operation (as is "read by date"). Perhaps they were put here with "Read" for discoverability. It could be argued that by date and and all read hose 2 don't belong in the mark hierarchy because these are "folder" operations. I would add - the _3_ items below "Read" also seem misplaced because they do not _toggle_ read state as do 4 of the other 5 items - they only mark messages UNREAD. (But "Mark thread as read" should be made toggle - no reason why it can't. New bug?)
Partly bug 377113, I think.
with bug 454829 and bug 452440 we should be moving to a system of showing buttons (in the message pane) that provide actions relevant to the selection. I'm assuming that this will be fixed or at least mitigated by this new system.
let's get this off of unconfirmed
Status: UNCONFIRMED → NEW
Depends on: 454829, 452440
Ever confirmed: true
Yeah this bugs me too that I went to get an addon called mark all read. I much prefer the way Eudora does it with an option that marks it as read and another that marks it as unread. This is regardless of the status so that it works against a mixed group of messages that have different read/unread statuses.
Is this bug about "Mark as read" behaviour as well? The summary only mentions "Mark all read" and "Mark thread as read", but the bugs that have been duped here lately were dealing with "Mark as read". Maybe adjust summary? Most important for me would be consistent behaviour for the M shortcut if some of the selected messages are unread. Intuitively I'd prefer all marked as read whenever there is a single unread one. Marking all as unread if all are read would be OK for me, though I have no strong opinion there. Use case: read a mail, consider it uninteresting, and mark some related messages (i.e. part of a thread, or unthreaded but on the same topic nevertheless) using shift+click on the last, then press M. I always have to press M twice, because the first mail is read, while the others are not. A single key press would be better and less annoying.
Yes this thread is about the behavior of "Mark as read". It doesn't always do what you want it to do due to the stats of the message that it is on when it is selected. If a feature needs to be explained, it's not a good feature.
Martin, I have a patch for the issue you're describing in bug 575732.
Severity: trivial → S4
You need to log in before you can comment on or make changes to this bug.