364348 - unexpected tag list behavior selecting multiple messages

Status: NEW

(Thunderbird :: Mail Window Front End, defect)

Description

[Martin Meyer]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20060601 Firefox/2.0 (Ubuntu-edgy)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1) Gecko/20061218 Thunderbird/2.0b1 ID:2006121804

When I have a thread of messages that should all receive a certain tag, the messages obviously don't come in all at once. I might tag the first few and forget for a few messages, then want to re-tag the whole lot of them a little later.

When you open the Tag drop-down from the toolbar, it seems to populate the check column with the tags applied to the first selected message. It doesn't even consider that the last X messages have no tags applied at all.  As a result, clicking the "news" tag unsets that tag from all messages rather than applying it to the ones that are not yet marked with it. This is the opposite of the expected behavior, and the opposite of how most other apps would handle the situation. 

It might also be useful to indicate that some of the selected messages have a tag applied, maybe with a partially grayed-out check or something?

Reproducible: Always



Expected Results:  
Clicking the "news" tag again should set that tag to all selected messages.

Comment 1

[Karsten Düsterloh]

> it seems to populate the check column with the tags applied to the first 
> selected message.

Yes, we take the tag state of the first selected message to init the menu, just like we do when marking messages as (un)read. The only difference here is that "multiple (un)read states" are shown, i.e. the different tags.

> clicking the "news" tag unsets that tag from all messages rather than applying 
> it to the ones that are not yet marked with it. This is the opposite of the 
> expected behavior

Is it really? How'd you remove a tag from all selected messages then?

> It might also be useful to indicate that some of the selected messages have a
> tag applied,

Yes, albeit this may slow down opening times for large message selection dramatically (we'd to look at each message before opening the menu)!

> maybe with a partially grayed-out check or something?

More "something", if at all.

So, in fact, we have these possibilities (plus their respective opposites):

- don't preselect states from the first message, always assume unset => you can't unset tags anymore

- preselect states based upon all selected messages, differing between set/partially set/not set => will get quite slow very quickly

These alternatives don't look very appealing to me...

Comment 2

[Mike Cowperthwaite]

(In reply to comment #1)
> - don't preselect states from the first message, always assume unset =>
>   you can't unset tags anymore

You don't have to *always* assume unset, but you can force unset if *any* set rather than if *first* set.  Then if the intent was to set the tag for all, it would require two selects of the same menu item instead of one (or changing the selection)

This same basic bug has been reported elsewhere for the Mark | As Read item
(bug 102518, bug 223073) and for Mark | Add Star (bug 257885).

Comment 3

[Karsten Düsterloh]

> You don't have to *always* assume unset, but you can force unset if *any* set
> rather than if *first* set.

That's basically the same as "preselect states based upon all selected messages" - whether I create two or three states when looking at all selected messages doesn't matter. 

> This same basic bug has been reported elsewhere for the Mark | As Read item
> (bug 102518, bug 223073) and for Mark | Add Star (bug 257885).

The basic bug is our poor performance in accessing the relevant date, even more so when doing it for several folders (imagine selections in virtual folders!).
I'd love to see a solution...

Comment 4

[Mike Cowperthwaite]

(In reply to comment #3)
> > This same basic bug has been reported elsewhere for the Mark | As Read item
> > (bug 102518, bug 223073) and for Mark | Add Star (bug 257885).
> 
> The basic bug is our poor performance in accessing the relevant date, even
> more so when doing it for several folders (imagine selections in virtual
> folders!). I'd love to see a solution...

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 (only in the context menu?) 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: 

A checkbox is presented for each attribute (unread, star, and one for each tag).  Each checkbox has three states: checked, unchecked, checked-but-dimmed (meaning some items have the attribute).  Then clicking the box cycles either toggles (if the original state is checked or unchecked) or cycles thru unchecked, checked, dimmed (if the original state is dimmed).

- I'm actually not fond of the "dimmed-but-checked" appearance as the dimming implies "disabled"; a better graphic for this third state would be desirable.
- This could be done as separate dialogs for the Tags vs. the Unread/Star, but I don't really see the need of this.
- While Junk could also be handled this way, we already have separate As Junk and As Not Junk commands, so it seems unnecessary.
- I say "only in the context menu" because the context menu already changes when multiple messages are selected.  Meanwhile, in the Message Menu, the Mark & Tag items could change their behavior when multiple messages are selected, either: (1) disabled so not accessible or (2) always mark, never unmark, for multi-selection.