180004 - Better handling of 3 state junk button/icon

Status: NEW

(Thunderbird :: Folder and Message Lists, enhancement)

Description

[Jean-Francois Ducarroz]

When the spam status of a message is undecided, if you want to set it to
no-spam, you have to click twice on the spam button or in the spam icon the the
spam status column. It would be nice to have a quicker way either by changing
the toggling order (spam-nospam to nospam-spam) or be able to do shift-click.

Comment 1

[Dan Mosedale (:dmosedale, :dmose)]

Shift click sounds OK to me.  Changing the toggling order seems like it would
just move the problem around.  jglick, any thoughts?

Comment 2

[jglick]

I've found that during training, i'm marking more msgs as Not Spam as well. 
If we think this will be the case for most users, i'm ok with switching the 
toggle order to Unknown, Not Junk, Junk, to make training easier.

Once system has been training for a while though, yeah, its probably a draw as 
far as what is more common. Actually, hopefully users won't have to toggle much 
once the system is trained. :-)

Either switching the order or Shift click is ok w/me.

Comment 3

[Jean-Francois Ducarroz]

Personnaly I think both solution are needed. The ordering change is normal users
and the shift click is for advanced users

Comment 4

[jglick]

Both is fine w/me too.

Comment 5

[Dan Mosedale (:dmosedale, :dmose)]

Attachment: cycler order change patch, v1

OK, this changes the cycler and the toolbar button order to be
Unknown->Not-Junk->Junk.  For the cycler, this makes sense, for the toolbar,
I'm not sure: given the picture that is used in the toolbar button, selecting
an Unknown message and clicking the toolbar button makes me expect that message
be set to Junk.  Instead, with this patch, it will be set to Non-Junk.	jglick,
any thoughts on this?

As far as shift-click goes, the outliner code currently doesn't pass any
modifier key info into nsITreeView::CycleCell.	In some future world, it
hopefully will.  But for now, the only way to implement this would be to add an
onclick handler to the entire threadpane tree, which seems like a heavy perf
price to pay given that such a tiny percentage of clicks inside the threadpane
are likely to be shifted clicks of the junk mail cycler.

Comment 6

[jglick]

>given the picture that is used in the toolbar button, selecting
>an Unknown message and clicking the toolbar button makes me expect that message
>be set to Junk. 

Yeah, i'd agree. Good point. And the button action and the column action should 
probably match each other. I know its a pain when first training to have to 
click twice, but it might be better to keep the behavior/order of the toolbar 
and column the same. Cc'ing others for opinion.

Comment 7

[Jean-Francois Ducarroz]

Seth was saying yesterday that he wants to remove the unknow state! maybe you
should check with him before going forward on this bug...

Comment 8

[Joe McCabe]

What about clicking in the column goes Unknown -> Junk -> Not-Junk, but the
toolbar icon follows the same sequence in addition to being a pop-down menu (ala
Forward and Back) with: "Message is Junk," "Message is not Junk," "Run Junk
controls on selected," and "Configure Junk Mail controls"

Comment 9

[scottputterman]

I also think we should remove the unknown state.  I don't think the state should
matter to the user unless it's wrong.  Keep the unknown state in the code, but
show it to the user as not spam.  If it is spam then they can train it.

Comment 10

[jglick]

Doesn't marking Unknown msgs as Not Junk train the system as well?

Comment 11

[Christian Williams]

how about at least a preference for showing the unknown state?  i find it hard
to understand what the junk filter thinks it has learned if i can't tell what
it's looked at so far...

also [and sorry this is slightly off-topic], does the filter retain what it has
learned about messages that have been classified but then deleted?  perhaps that
should be mentioned in the junk mail controls or help.

Comment 12

[Dan Mosedale (:dmosedale, :dmose)]

Assigning bugs that I'm not actively working on back to nobody; use
SearchForThis as a search term if you want to delete all related bugmail at
once.

Comment 13

[Serge Gautherie (:sgautherie)]

Filter on "Nobody_NScomTLD_20080620"

Comment 14

[Wayne Mery (:wsmwk)]

This idea doesn't seem to be much in demand (unless there are other bugs about this) - no dups, no votes, and almost no cc.  And also not discoverable - no mouseover tooltip

Comment 15

[Kent James (:rkent)]

(In reply to comment #14)
> This idea doesn't seem to be much in demand (unless there are other bugs about
> this) - no dups, no votes, and almost no cc.  And also not discoverable - no
> mouseover tooltip
The reason it is not in demand is that the unknown status was removed, so this bug does not really make sense any more.