Bryan Clark (DevTools PM) [:clarkbw] Reporter
	Description • 15 years ago

I'm not sure why we didn't add the junk button to our multi-message selection but it's obviously missing among the archive and delete buttons.

There is an additional problem here because there isn't an easy way to unjunk multiple messages.  The toolbar has traditionally punted on this problem by only offering unjunk if all the messages are junk or if the first message in the selection was junk.  We could at least offer this same behavior to prevent regressing and yet know that we just aren't doing a very good job.

This change might require new strings and as such might have to be punted to the 3.1 timeframe.  I'm not sure if this should block the 3.0 release.

	Kent James (:rkent)
	Comment 1 • 15 years ago

(In reply to comment #0)
> 
> There is an additional problem here because there isn't an easy way to unjunk
> multiple messages.
> 
This issue only arises because you are thinking of this as "unjunk" which is not the most general way to think of it. The junk and not junk functions train the filter that the message is junk or good, and also have all of the side effects associated with that (such as moving the message). From my perspective, you are focusing on the side effect, and missing the primary function. This has been a difficult distinction to explain unfortuantely. I guess that is why it is difficult in the standard UI to mark a non-junk message as good, which is really critical to the proper functioning of the junk mail filter.

You can solve this very easily on multi-message selection by offering both junk and not junk buttons. Applying that would affect all of the messages in the selection. It would be helpful to offer some method to mark messages as not junk quickly and easily such as this.

In the long run, the only way that I see around this is to automate the training of messages as good. In JunQuilla, I plan to experiment with using whitelisted messages as a source of trainable good messages.

	Bryan Clark (DevTools PM) [:clarkbw] Reporter
	Comment 2 • 15 years ago

(In reply to comment #1)
> (In reply to comment #0)
> > 
> > There is an additional problem here because there isn't an easy way to unjunk
> > multiple messages.
> > 
> This issue only arises because you are thinking of this as "unjunk" which is
> not the most general way to think of it. The junk and not junk functions train
> the filter that the message is junk or good, and also have all of the side
> effects associated with that (such as moving the message). From my perspective,
> you are focusing on the side effect, and missing the primary function. This has
> been a difficult distinction to explain unfortuantely. I guess that is why it
> is difficult in the standard UI to mark a non-junk message as good, which is
> really critical to the proper functioning of the junk mail filter.

Sorry I always merge those two incorrectly.  We should probably continue this discussion in the newsgroups because I'm actually really interested in working on the UI for this though this isn't the right bug.  From a UI perspective I would like to try thing that use parts of the address book for "notjunk" filtering because I think they have a very close relationship that we could possibly model (and would make it easy for people to understand).  Anyway, feel free to start a thread on future junk training UI and I'll add my thoughts there.

	Bryan Clark (DevTools PM) [:clarkbw] Reporter
	Comment 4 • 15 years ago

Hit return too early and uploaded the old (non-working) version of the patch.

This patch adds a junk button to the muli-message view header.  It does add a new junk string so there is l10n impact with this patch.  It does seem like I could create a new patch that reuses the string from the message header if we wanted to get this in for TB3.0

	Jim Porter (:squib)
	Comment 5 • 15 years ago

For 3.1, I think it would be best to use the toolbar from the single message header, and just hide irrelevant buttons (e.g. reply). This would have the benefit of making bug 519956 apply to both sets of buttons. Of course, that might make things a little weird if you customized the toolbar from the multi-message view (how do you drag the invisible reply button?).

	Bryan Clark (DevTools PM) [:clarkbw] Reporter
	Comment 6 • 15 years ago

Here's a further patch that adds a "not junk" button as needed.  If there exists either a junk or nonjunk message in the selection either the nonjunk or junk button will appear, respectively.  This interaction allows a user to set a list of mostly junk messages as all junk or vice versa.

When a person chooses Junk or Not Junk the header buttons will update underneath the mouse.  This does create a possible problem that a person double clicking would do and then undo immediately.

	Blake Winton (:bwinton) (:☕️)
	Comment 7 • 15 years ago

Could you disable it for a little while after they click, to avoid the double-click?

	Bryan Clark (DevTools PM) [:clarkbw] Reporter
	Comment 8 • 15 years ago

(In reply to comment #7)
> Could you disable it for a little while after they click, to avoid the
> double-click?

I suppose, though those kind of tricks are usually hard to get right every time.  But adding a simple 1 - 2 second timeout does seem like it would be simple enough and would work well.

	Bryan Clark (DevTools PM) [:clarkbw] Reporter
	Comment 9 • 15 years ago

(In reply to comment #5)
> For 3.1, I think it would be best to use the toolbar from the single message
> header, and just hide irrelevant buttons (e.g. reply). This would have the
> benefit of making bug 519956 apply to both sets of buttons. Of course, that
> might make things a little weird if you customized the toolbar from the
> multi-message view (how do you drag the invisible reply button?).

I had wondered if we could just respect the removal of buttons from the header view instead of making this a further customizable heading.  i.e. if you removed the ( archive ) button from the header view we would just not show it on the multi-message header as well.  Though I suppose people _might_ want to have archive and junk available for multiple selections and not for individual messages.

The added customization of the multi-message view header buttons seems a bit excessive, at least to me.  Also note that there are two modes, one is the Thread Summary view and the other is the Multiple Selection view.  I'm not sure if people would want to customize those separately.

	Jim Porter (:squib)
	Comment 10 • 15 years ago

(In reply to comment #9)
> I had wondered if we could just respect the removal of buttons from the header
> view instead of making this a further customizable heading.  i.e. if you
> removed the ( archive ) button from the header view we would just not show it
> on the multi-message header as well.  Though I suppose people _might_ want to
> have archive and junk available for multiple selections and not for individual
> messages.

Well, my idea was to use the very same toolbar, but force irrelevant buttons to be hidden, so that customizations are reflected in both directions. Personally, I don't see a need for one button to be present in the multi-message (or thread) summary, but not present in the message header. Maybe there is a need to customize them separately though.

	Thomas D. (:thomas8)
	Comment 11 • 15 years ago

I appreciate that we may not have the time to get these things in for tb3.0, but can we please stop that bizarre discussion whether things should be customizable separately or not and how to tweak things together that are really separate. We've had that useless discussion before for the single mail header, and what we can really take away from that is that separate customization is a must. Everything below that is not sustainable in the long run, as different users have different needs. It's not expecting too much of a modern app that I can choose toolbar buttons for different spots according to my needs and usage patterns.

	Bryan Clark (DevTools PM) [:clarkbw] Reporter
	Comment 12 • 15 years ago

like a lot of my other bugs I'm going to hand this over to blake to land for the 3.1 time frame

	KitchM
	Comment 13 • 15 years ago

I share the frustration over Bryan's problem, for it is mine as well, and I agree with Jim's more simple and streamlined method.

I was particularly surprised that this problem still exists after so long.  Clearly a case of bad defaults setup, the ability to do the same thing with multiple selections as with a single selection has been eliminated by no Junk button on the button bar.  When the program is installed, the default layout is confusing for lack of that button, and for the inclusion of a second button bar in the header area of the email in focus.  Very strange!

The intuitive nature of the interface is lost when we don't think these things thru.  There is no conflict between the filtering, junk and addressbook mechanisms.  Rather, the designers have lost the understanding of the natural order of things.  Further, the ability to change the display based upon selections has been misapplied when multiple selections have been made.  With the failure to provide a junk button on the button bar as a default of the installation process (as well as an Undo button, I might add), the hiding of the only available one, once a second selection is made, is simply and obviously hampering the user's efforts.  This is not hard to understand.

In this case, the user must be the final arbitor.  She chooses the action to apply to the email(s).  Following this is the need to be able to undo whatever is done.  All other functions must follow this natural order of use.

Never, ever is the user to be slave to doing things a particular way.  The software must be the servant.  I must be able to select any number of items to commit as junk or to archive or whatever.  The same buttons must apply to such selections.  Confusion comes about, when this is not done in this manner.

(Further, instead of selecting and handling in groups, it would have been better to allow a simple click-tagging similar to the read/unread buttons for a whole series of emails with choices of junk, archive, read, trash, etc. and then allowing one process button to sort at one time.  That's even better IMHO.)

There is no exception and no excuse.  What we simply have here is bad design that needs a little thought.  In fact, I am convinced that the solution to this problem will bring with it a streamlining of the whole application code and design.  That's win/win.

Thank you.

	Bryan Clark (DevTools PM) [:clarkbw] Reporter
	Comment 14 • 15 years ago

Comment on attachment 408907 [details] [diff] [review]
add junk button to multimessage selection w/ new "junk" string

This still applies and works.  At a minimum it will give us the Junk button for multiple messages.

Magnus can you take the review of this?

	Magnus Melin [:mkmelin]
	Comment 15 • 15 years ago

Comment on attachment 408907 [details] [diff] [review]
add junk button to multimessage selection w/ new "junk" string

This doesn't seem to work. (Went to my junk folder and selected two msgs, hit the junk button. The button shows but does nothing.)

Error: window.top.DefaultController.goDoCommand is not a function
Source File: chrome://messenger/content/multimessageview.xhtml
Line: 1

	Magnus Melin [:mkmelin]
	Comment 16 • 15 years ago

Should probably be doCommand

	Magnus Melin [:mkmelin]
	Comment 17 • 15 years ago

But even then, it's quite odd if you select two junk messages (already marked as such), the button still shows "junk", but hitting it will actually unjunk them. Like comment 1 suggests, having both buttons might be best, or at least the button need to take the current status into account.

	KitchM
	Comment 18 • 15 years ago

Absolutely correct; the button needs to take the current status into account.  Thanks Magnus.  Not only that, but it  needs to change its icon based upon the state of the target messages.

I suppose there is a problem when the selected group of messages are each toggled different ways in regards to junk status.  However, just having the basic funcionality would be an absolutely huge benefit to all users.

	Jim Porter (:squib)
	Comment 19 • 15 years ago

There was a little bit of discussion about this in bug 514094 with regards to mark as read/unread (start around comment 6 for the meat of it).

	Bryan Clark (DevTools PM) [:clarkbw] Reporter
	Comment 20 • 15 years ago

(In reply to comment #15)
> (From update of attachment 408907 [details] [diff] [review])
> This doesn't seem to work. (Went to my junk folder and selected two msgs, hit
> the junk button. The button shows but does nothing.)
> 
> Error: window.top.DefaultController.goDoCommand is not a function
> Source File: chrome://messenger/content/multimessageview.xhtml
> Line: 1

Sorry about that.  Apparently I had moved right on to the next patch and this one was incorrect the whole time.

I updated the previous patch where I was trying to be fancy with the .some() function but really required looping through the whole array possibly twice in the worst case.

Something I looked into but then dropped was adding the updateMultiMessageButtons() call in the procesItems function of the MultiMessageSummary object.  This would mean that if Gloda noticed a change in the message the junk buttons would update accordingly.  However since Gloda doesn't notice junk flag changes this doesn't update when you junk or unjunk messages already selected.  It does update the button if you junk/unjunk and then also star or mark read/unread; which Gloda does watch.

I tried leaving this function call in but after playing with it for a little while I just found it confusing.  There is a certain delay for Gloda to update and then because it's not related to junk flags it seems more mysterious than helpful.  I think simple is best here.

  processItems: function(aItems) {

    /* Gloda doesn't listen for junk flag updates but this will at least catch
      if any of the messages are reindexed for other reasons */
    updateMultiMessageButtons();

	Bryan Clark (DevTools PM) [:clarkbw] Reporter
	Comment 21 • 15 years ago

Kent, I'd appreciate your feedback on this change.

Also, I can work on a mozmill test in a followup patch... unless kent wouldn't mind taking that over :-D

	Kent James (:rkent)
	Comment 22 • 15 years ago

My test build was out of date and needed clobering, so I was not able to actually test this. But reviewing the code, here are my comments.

There have been efforts to eliminate magic numbers from the mailnews code, and the junkscore == "0" is really a kind of magic number. Elsewhere, we have code that detects junk without magic numbers, using:

let isJunk = (junkScore == Components.interfaces.nsIJunkMailPlugin.IS_SPAM_SCORE);

I think that would be a better test than your:

((junkScore != "") && (junkScore != "0"))

Similarly, isGood is:

(junkScore != Components.interfaces.nsIJunkMailPlugin.IS_SPAM_SCORE)

You can treat junkScore as a tristate, with three possible values:

"" (not evaluated, assumed good)
Components.interfaces.nsIJunkMailPlugin.IS_SPAM_SCORE (spam)
Components.interfaces.nsIJunkMailPlugin.IS_HAM_SCORE (good)

On another issue, I have often complained that the standard junk UI makes it very difficult to train non-junk messages as "good", precisely because we disable the "train as good" buttons except when messages are marked as junk. I don't think that we should be doing that, as you do here. It results from a misunderstanding of "train as good" as "mark as good" (the buttons do both). With the code as proposed, a support article for getting junk mail started would need to read something like this:

"Before the automatic junk detection will work, you need to train both junk and good messages. So select a number of messages that you know to be good (at least 100), and train them as good. But you'll have to use the keyboard shortcut shift-j for that, because the standard UI disables all attempts to trian messages as good using buttons unless they are previously falsely marked as junk"

I would love to be able to get rid of that last sentence. If you leave up the "train as good" button here, I could do that.

	Bryan Clark (DevTools PM) [:clarkbw] Reporter
	Comment 23 • 15 years ago

(In reply to comment #22)
> My test build was out of date and needed clobering, so I was not able to
> actually test this. But reviewing the code, here are my comments.
> 
> There have been efforts to eliminate magic numbers from the mailnews code, and
> the junkscore == "0" is really a kind of magic number. Elsewhere, we have code
> that detects junk without magic numbers, using:
> 
> let isJunk = (junkScore ==
> Components.interfaces.nsIJunkMailPlugin.IS_SPAM_SCORE);
> 
> I think that would be a better test than your:
> 
> ((junkScore != "") && (junkScore != "0"))
> 
> Similarly, isGood is:
> 
> (junkScore != Components.interfaces.nsIJunkMailPlugin.IS_SPAM_SCORE)
> 
> You can treat junkScore as a tristate, with three possible values:
> 
> "" (not evaluated, assumed good)
> Components.interfaces.nsIJunkMailPlugin.IS_SPAM_SCORE (spam)
> Components.interfaces.nsIJunkMailPlugin.IS_HAM_SCORE (good)

Awesome, I've updated the code to reflect these changes.

 function updateMultiMessageButtons() {
-  let hasJunkMessages = false;
-  let hasNonJunkMessages = false;
+  let hasJunkMessage = false;
+  let hasNonJunkMessage = false;
 
   gFolderDisplay.selectedMessages.forEach(function(element) {
     let junkScore = element.getStringProperty("junkscore");
-    if (!hasJunkMessages) {
-      hasJunkMessages = ((junkScore != "") && (junkScore != "0"));
+    if (!hasJunkMessage) {
+      hasJunkMessage = (junkScore == Components.interfaces.nsIJunkMailPlugin.IS_SPAM_SCORE);
     }
-    if (!hasNonJunkMessages) {
-      hasNonJunkMessages = ((junkScore == "") || (junkScore == "0"));
+    if (!hasNonJunkMessage) {
+      hasNonJunkMessage = (junkScore != Components.interfaces.nsIJunkMailPlugin.IS_SPAM_SCORE);
     }
-    if (hasJunkMessages && hasNonJunkMessages)
+    if (hasJunkMessage && hasNonJunkMessage)
       return;
   });
 
   let cDoc = document.getElementById('multimessage').contentDocument;
-  cDoc.getElementById("notjunk").collapsed = (!hasJunkMessages);
-  cDoc.getElementById("junk").collapsed = (!hasNonJunkMessages);
+  cDoc.getElementById("notjunk").collapsed = (!hasJunkMessage);
+  cDoc.getElementById("junk").collapsed = (!hasNonJunkMessage);
 }


> On another issue, I have often complained that the standard junk UI makes it
> very difficult to train non-junk messages as "good", precisely because we
> disable the "train as good" buttons except when messages are marked as junk. I
> don't think that we should be doing that, as you do here. It results from a
> misunderstanding of "train as good" as "mark as good" (the buttons do both).
> With the code as proposed, a support article for getting junk mail started
> would need to read something like this:
> 
> "Before the automatic junk detection will work, you need to train both junk and
> good messages. So select a number of messages that you know to be good (at
> least 100), and train them as good. But you'll have to use the keyboard
> shortcut shift-j for that, because the standard UI disables all attempts to
> trian messages as good using buttons unless they are previously falsely marked
> as junk"
> 
> I would love to be able to get rid of that last sentence. If you leave up the
> "train as good" button here, I could do that.

I completely agree.  From what I understand of the changes that have been made recently we could even start offering ways to generically train the system (beyond just junk).  I would imagine to make this happen we would need to start changing all the ways in which people interact with the Junk filtering.  The first run needs a lot of help to get people pointed in the right direction.  And it seems to me that if you add someone as a contact we should be training the Junk filter on "good" at that moment.

I know you're not asking that those changes happen right now in this bug so we should open up a separate, maybe tracker bug, and then some specific action bugs that block it.  I'm happy to help with this post-3.1.  Selfishly I would want to start with the first use of Junk so I can ask people if they just wanted to move the message to their junk folder or if they wanted to start training their junk system.  As that's a common support / usability problem.

	Kent James (:rkent)
	Comment 24 • 15 years ago

You are still hiding the notjunk button unless there is at least one junk message in the list, which is ignoring the second half of my comment. I was proposing to always show that button so that users could train messages as nonjunk that have not been previously marked as junk.

	KitchM
	Comment 25 • 14 years ago

Thanks to all who are working on this issue.  It is so good to see the interest in the problem and the thoughtful work being done.  Keep up the great work!

	Bryan Clark (DevTools PM) [:clarkbw] Reporter
	Comment 26 • 14 years ago

(In reply to comment #24)
> You are still hiding the notjunk button unless there is at least one junk
> message in the list, which is ignoring the second half of my comment. I was
> proposing to always show that button so that users could train messages as
> nonjunk that have not been previously marked as junk.

Oh, sorry maybe I misunderstood you.  I thought to solve that issue we would be using a separate button like "Train as Good" or something similar instead of the "not junk".  Not junk seems too vague a term to be used for training messages for good as well as marking them 'not junk'.  I think I see the 'not junk' as more of an undo than a training button and that we likely want separate actions / buttons for those two items.

	Kent James (:rkent)
	Comment 27 • 14 years ago

Well the reality is that the current "not junk" is "train and mark as good" - which is identical to the function of your proposed "Train as Good" button. The only difference is that you are hiding it in contexts like we are discussing here. I doubt that you would really want to have two buttons that do the same thing, but have slightly different wording and hiding features.

	Magnus Melin [:mkmelin]
	Comment 28 • 14 years ago

Comment on attachment 433002 [details] [diff] [review]
updated patch with both junk and not junk buttons

>+    if (!hasJunkMessages) {
>+      hasJunkMessages = ((junkScore != "") && (junkScore != "0"));
>+    }
>+    if (!hasNonJunkMessages) {
>+      hasNonJunkMessages = ((junkScore == "") || (junkScore == "0"));
>+    }

No braces needed for one line if statements. Also like rkent said, please don't use magic numbers.

>+  let cDoc = document.getElementById('multimessage').contentDocument;

Prefer double quotes if there's no need to use single ones. (Makes files more consistent.)

>+  cDoc.getElementById("notjunk").collapsed = (!hasJunkMessages);
>+  cDoc.getElementById("junk").collapsed = (!hasNonJunkMessages);

Please loose the parenthesis.

I might go for showing the "not junk" also if there's unclassified messages selected.

	Kent James (:rkent)
	Comment 29 • 14 years ago

(In reply to comment #28)
> 
> I might go for showing the "not junk" also if there's unclassified messages
> selected.

That would help a little, as it would allow people to start with junk processing off, train some messages as good, then turn on junk processing. But it does not help the ongoing issue that people need to be able to explicitly tell the bayes filter that certain messages are truly good messages. It is not really relevant that they have been marked as good by the junk filter, because marking as good is not the same as training as good. There is an ongoing need to train messages as good, and that is why I can't understand the reluctance to show a button to train as good, even when all messages are marked as good.

Could you guys who are against this please explain to me why?

Just to be clear: junkscore == 0 means marked as good. Trained as good is (junkscore == 0 && junkscoreorigin=='user'). The unjunk process both marks as good, and trains as good. There is a need to train messages as good for proper operation of the bayes filter. The UI should support this, and currently does not - in fact if actively fights against it, which this bug is attempting to perpetuate. If you want to disable the button when it is truly meaningless, then you will need junkscore == 0 && junkscoreorigin == 'user'.

	Magnus Melin [:mkmelin]
	Comment 30 • 14 years ago

At least for me the main reluctance is that that even if training as good is good for the user, very few users would (actively) want to do that. Users just want stuff to work and not have software make them feel obligated to do chores. Marking as bad has a more direct reward in that the message is deleted/moved away.

That said i do understand your point and can't say i have a strong opinion against the ui exposing training either.

	Kent James (:rkent)
	Comment 31 • 14 years ago

"very few users would (actively) want to do that"

No disagreement there. But for those with clue, and who are willing to do that, we should not actively fight them by disabling the options that they need.

Personally I have been experimenting with automatic training of good based on the address whitelist, using FiltaQuilla's "Train as Good" filter action. I should really do a test of that concept with a standard spam corpus, but those tests are surprisingly difficult to do. Probably instead I will just add this as a standard feature at some point to JunQuilla. I generally think that the correct approach is to have an extension that makes the local junk management work better rather than cluttering core with these issues, as so many people are happy with their server-based approach and don't need TB's bayes filter very much.

	Bryan Clark (DevTools PM) [:clarkbw] Reporter
	Comment 32 • 14 years ago

Not to "take my ball and go home" but I have a bunch of blockers to get done.  I tried to get this fixed in my spare time but I can't take the time to tackle both the question of proper training as well as make the junk / not junk buttons available (at least in their current form) while viewing multiple messages.

If we want to have this patch land we should tackle the training issue in a separate bug.  There is a lot of fallout and unknowns related to changing how people interact with the junk filtering; none of which I have time to take on right now.

I'm sorry, I'm not upset, even if this comment sounds it.  I'm just overworked and a bit exhausted.

	KitchM
	Comment 33 • 14 years ago

It appears that there is a basic misunderstanding within the dialog here.  It seems to me, and please correct me if I am wrong, that the email that comes into the mail client software is either, and only, spam or legitimate.  With that said, the point of filtering is to make sure that the spam is added to the blacklist, and the legitimate is added to the whitelist.

To do so, I first let the automatic filter do its thing.  I then check my inbox for spam that was not noticed by the filter and marked it as spam by selecting it and using the Junk button.  Then I check my spam to see if something got marked as spam that should be legitimate.  I select any such and use the Not Junk button.

This leaves the email that is not junk but which I review and simply delete.

All but the last step is assumed to be connected to the white- and black-lists.  Are you guys saying that such is not the case?

	Kent James (:rkent)
	Comment 34 • 14 years ago

KitchM: What you are saying is approximately correct, but you are missing one key issue. And that is: ideally, the junk filter NEVER marks a legitimate email as junk. And that is how I operate and recommend to others that they operate.

What you are suggesting would work if the user was willing to accept the same number of false positives (good email marked as junk) as false negatives (junk email marked as good.) But that is not the case. In my case, I have absolutely no false positives, either in my front-end SpamAssassin, or my backend TB bayes. So I never "check my spam to see if somethings got marked as spam that should be legitimate" because it is not necessary, and therefore using your method, I would never mark anything as good.

But what you describe is the method that the Thunderbird front end supports, and therefore implicitly encourages users to adopt. But when the junk filter starts to work correctly (by which I mean no false positives), users only train junk and not good, which is guaranteed to eventually force the junk filter to start generating false positives. False positives are always very evil, and we should not design the front end to force the junk filter to go that direction to beg for some training of good.

JunQuilla and the "Uncertain" folder is for me the current solution to this issue. But without JunQuilla, the "proper" way to use TB's spam filter should be to routinely mark false negatives as junk (which everyone does), and occasionally select a large group of known-good messages and train them as good (which the current UI makes impossible, except using the keyboard shortcut shift-J). Now I will admit it is the rare user that will actually do this, which is why we need JunQuilla's Uncertain folder, or train-as-good using the whitelist. But I still do not understand why we want to actively discourage that rare user by disabling the feature (mark as good) that they need to actually do what there are supposed to do.

	KitchM
	Comment 35 • 14 years ago

Thanks, Kent.  I get your point.  I agree with the basic concept.  However, I believe that you are missing the really ultimate solution.

As I understand the whole situation within the industry, one must be able to train SpamAssassin with feedback.  That must absolutely be done from the client software if the average user (such as someone who actually gets one's own domains hosted) wants to do the job right.  (They may also wish to use a tarpit, which requires that the training be very accurate.)  Only this way will the system work and actually eliminate false positives and negatives from ever getting to the client.  This job does not end at the client sofware; it has only begun there.  The server and client software programs must have two-way communication regarding spam training, under the control of the user.  IMHO anyway.

Further, are you suggesting that TB requires the use of a particular plugin to work correctly?  I could be wrong, but it seems to me that such is sending the wrong message.

I can see no way that the end user will ever be completely free of checking their received mail, if they are going to join in the fight to stop spam as the system works now.  (And before anyone asks, yes, I do know how to stop spam, at the national level anyway.)  Right now I think that the best we can do is to make TB work in a more intuitive manner regarding this issue, and only then discuss the overall issue of handling spam in one way or the other.

	Kent James (:rkent)
	Comment 36 • 14 years ago

KitchM: The goal of this bug is not to address broader issues of spam management in TB, but simply to get junk buttons added correctly to the multiple selection. If you are interested in discussing spam management strategy in general, the m.d.a.t forum might be a better place, or in another bug. My comments so far have been primarily directed toward justifying why I think that the "not junk" button should remain enabled even when all selected messages have been previously marked as junk.

	KitchM
	Comment 37 • 14 years ago

Kent: Yes, of course.  However, if we don't know where we're going, all sorts of problems will pop up.  We may duplicate steps unnecesarily, we may cause undue confusion in the product, or we may mislead the user in things related to email.  These are very important issues in that they can cause us to use the wrong justification for programming choices.

No matter what happens, I believe that the user deserves choices which allow them to use the product in the way that best serves their manner of work and thought process.  Completely customizable button choices are a necessity, and that would imply that the all sorts of buttons be made available.  If a button cannot be toggled between two states, then two buttons must be proivded.  One for Junk and one for Not Junk.  Then these both must be available all the time.

Further, selecting more than one message at a time would automatically sync them all with the button selection.  So if I select Junk, the three already tagged as junk and the two that weren't would all become Junk.  And of course vise versa if Not Junk is selected.

	Jonathan Protzenko [:protz]
	Comment 38 • 14 years ago

I filed bug 561859 some time ago. However, I decided it's too complex and I don't think I will implement it in the near future. But if you want to fix it as a side effect of fixing this bug, feel free =). Plus, it might be helpful if you decide to implement the whole sequence of actions one day for your "junk" button.

	KitchM
	Comment 40 • 14 years ago

We don't seem to be going anywhere with this.  I've just starting using 3.1 and this problem still exists.  Does anyone know anything about the efforts to fix this and the behind-the-scenes work on this simple problem?

Thanks.

	Joachim Herb
	Comment 41 • 14 years ago

I guess this is a special case of bug 523544

	KitchM
	Comment 42 • 14 years ago

Yes, I think that the real issue is to admit that there are a lot of little problems that stem from the same bad code area.  Once we step back and see that there are many bugs within the same area, it becomes more clear that there are parts of Thunderbird that need a complete rewrite from the foundation up, IMHO.

	Jim Porter (:squib)
	Comment 43 • 14 years ago

Then by all means, feel free to submit a patch.

	KitchM
	Comment 44 • 14 years ago

Please stay on topic.  We need to get the coders to understand the issue here and point them clearly to the solution.

	KitchM
	Comment 45 • 14 years ago

Here's a workaround for this problem.  Install the CompactHeader extension.  Set it to display two lines in compact view.  Then customize the header buttons by removing them all.  Go to the button bar and add the ones you'd like to have.

This has the added advantage of cleaning up the too-busy header area, and making it smaller.  And also it puts the buttons back on the button bar where they belong.

I don't want to try to learn how to patch the program, especially since it is patched enough already.  Until a rewrite comes along, this will clean up a bad interface and get rid of the problem anyway, since the button bar's junk button works with multiple selections.

	Bryan Clark (DevTools PM) [:clarkbw] Reporter
	Comment 46 • 13 years ago

I shouldn't be the assignee for these bugs.  Filter against clarkbfilter to delete all these from your emails.

	Wayne Mery (:wsmwk)
	Comment 47 • 13 years ago

rkent, is your UI review pending ability to see an updated patch?

	Kent James (:rkent)
	Comment 48 • 13 years ago

I wasn't actually asked to do UI review, but give feedback instead.

Anyway, I tried to build with this in comm-central (after fixing the one section that would was rejected), and I cannot get it to work. That is, I get no junk or unjunk button ever with multiple message selected.

But really, the review is more feedback on the concept. This patch continues to ignore the advice I have been giving in all of my comments, that it is necessary to include an unjunk button even when there are no junk messages present. That is, the code:

hasJunkMessages = ((junkScore != "") && (junkScore != "0"));

will be false for bayes-classified good messages, and prevent the notjunk button from showing, and allowing messages to be trained as junk. I've described this issue at length in my previous comments on this bug.

I just don't understand why the UI has to be designed to work the way you would wish that the bayes filter worked, rather than match the way that it actually works. You need to train good messages. I know that is inconvenient but that is how the bayes classifier works. Others disagree with me on the UI, which is their right, but if you ask for my feedback, that is what I have to give.

	Kent James (:rkent)
	Comment 49 • 13 years ago

Two additions:

First, I was loading the running the wrong build, and when I run the correct one the patch (with correction for code drift) works.

Second, this patch is an improvement over the current situation, where the junk and non junk buttons disappear completely. So if the decision is to ignore my advice (to show the nonjunk button more frequently), then please let's do the patch anyway.

If I could get buy-off on the decision to include the nonjunk button even when there are no junk messages present (unless junkscore == 0 && junkscoreorigin=='user') I would be happy to submit a corrected patch with that change.