Closed Bug 775665 Opened 12 years ago Closed 12 years ago

Change Filter Context UI to checkboxes

Categories

(MailNews Core :: Filters, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 19.0

People

(Reporter: rkent, Assigned: aceman)

References

(Blocks 1 open bug, )

Details

Attachments

(2 files, 7 obsolete files)

(This is a followup from bug 479823  comment 0)

Comment on attachment 643864 [details]
An idea how the Filter Rules could look

This would be a useful feature, as would the similar filter on send.

The issue to me is the UI above. What you have done is the natural extension of this, and exactly what I did ("Checking mail (after classification) and "Checking Mail (after classification or Manually Run" are my additions).

But we are running into a combinatorial explosion here. The original mistake was the first change, with taking two features ("Incoming" and "Manual") and adding three options for that when what we should have had was checkboxes. The same filter should be able to applied in any valid combination of contexts without requiring 4,8,16, or 32 choices as we add features.

I suppose what would be useful is another bug to change this UI, and make the current bug and the "Filter on Send" bug dependent on it.

I have an aversion to opening enhancement requests that I am not going to undertake myself, but aceman if you would like to take a stab at the UI change, then we might be able to move forward with these other very important bugs.
Assignee: nobody → acelists
Blocks: 479823, 11039
So the dropdown list of 7 combinations events when to run the filter should be converted to an array of checkboxes, like this:

Apply filter when:
# Checking Mail
#   (after classification)
# Manually Run
# <some possible new event>

The events can be chosen in any combination.
OS: Windows 7 → All
Hardware: x86_64 → All
Yes that's the general idea. There are complications though (like incoming can be either before or after classification, but not both).

I'm not sure what to do with "after classification". It allows you to filter after the junk mail processing occurs, so that you can use the junk-related filter searches, at the cost of delaying your message filters until after the whole batch is received. I doubt if many people understand that though. In retrospect that should have been detected automatically.

But the checkboxes seem the best way to go so that we can add "After Send" and "At Archive" in the future. Not sure if "Before Send" makes sense or not.
It seems that we eventually start to address the issues in filter function.

aceman, you mentioned a simple list of checkboxes, but I rather like what I tried at bug 11039, attachment 423202 [details].

rkent, I think "before send" is more useful than "after send". Many people asked me whether I can apply filters before sending because they want to avoid some often-mistaken cases or they want to add some special headers to certain messages or other reasons. On the other hand, most people use "after send" to move or tag messages, which in fact can be alternated by using search folder for most cases.
I also like xzer's proposal. Do you understand what the issue was with it? As far as I can tell it was just "let's talk about it".
Yeah, why can't that patch be finished? xzer, can you finish it? It looks like what we want. The difference is that the bug here is only to rework existing options (UI) and not add any new backend so it should be easier to land.
Bug 11039 already adds the filter at send time functionality.
I think I can try to pick up the patch again and commit a smaller fix for UI style change only at first. For the send time functionality, I am not sure whether I can have time to finish it, it is so long ago....

Any way, we can have a start here.
I recommended this bug because shorter bugs are easier to review and land. So if we could get this landed, then the front end issues would be largely resolved, and we could then only deal with the backend changes needed to the filters to add the additional contexts.
xzer, that would be great. Please try to revive and split the patch into the 2 bugs. If after that you do not find enough time to drive the patches until checkin, we can probably help you (I'd try the UI patch that you attach here, rkent may finish the backend in bug 11039).
(In reply to Kent James (:rkent) from comment #2)
> I'm not sure what to do with "after classification". It allows you to filter
> after the junk mail processing occurs, so that you can use the junk-related
> filter searches, at the cost of delaying your message filters until after
> the whole batch is received. I doubt if many people understand that though.
> In retrospect that should have been detected automatically.

Indeed, we should probably fix that if it's going to be checkboxes, or the UI easily grows large enough to be very confusing.
xzer, you can also give us permission to use your patch and split/update it as needed.
Attached patch change filter ui to checkboxes (obsolete) — Splinter Review
Sorry for being late. I have split it to two patches, but there are some compile errors in the second patch for send filter functionality due to a disappeared class. I think I have no time to fix the second patch in the next week, so it would be nice if anybody could take it over if we want to finish it as soon as possible.

Btw, where should I submit the uncompleted send filter functionality patch? I don't know whether the original bug 11039 is an appropriate place since it depends on the UI patch.
Attached patch patch for send filter (obsolete) — Splinter Review
I temporarily submit the send filter patch here, please be careful of that it is a uncompleted patch because of missing deprecated class.
I'm proposing that we do the UI change here separately from bug 11039 (and initially without the send feature) to simplify moving forward with 11039 and the similar "on archive" bug. So at least for now, this is the correct place for the UI patch.

But you have submitted the send filter patch together with the UI patch. Could we split off the UI portion, and just try to do that first (without the Send feature)? IIRC that was the sticking point anyway in making progress with 11039, and smaller patches are generally preferred and easier to review.
To not complicate the UI for filters further, making it even more scary, I'd suggest to move these "run when" checkboxen into a secondary dialog (or, if you wish, expandable, default hidden). Incoming, outgoing and manual would be checked by default - because I think most users will want this - and only disabled when you go to this UI.
rkent

Because I have no time in this week and I want to have a place to share my current stage so that others can take it over if there are someone wanted.

I am sorry if here is a bad place for this purpose, anyway, I think the first patch for UI change can be reviewed and tested now.
xzer, have you found some time for the patch? Or can we start to work on it instead of you?
Comment on attachment 646577 [details] [diff] [review]
patch for send filter

This is moved to bug 11039.
Attachment #646577 - Attachment is obsolete: true
(In reply to Ben Bucksch (:BenB) from comment #15)
> To not complicate the UI for filters further, making it even more scary, I'd
> suggest to move these "run when" checkboxen into a secondary dialog (or, if
> you wish, expandable, default hidden). Incoming, outgoing and manual would
> be checked by default - because I think most users will want this - and only
> disabled when you go to this UI.

I'd agree with the expandable version so I'll implement it if I get the chance. Otherwise here is the screenshot of how the feature should look like according to the patch attached: https://bugzilla.mozilla.org/attachment.cgi?id=423202 .
:aceman 

Sorry, I think it is really hard to me to get time to complete the work. I give it up, please take it over.
Thanks for your work on the patch so far.
I think I understand how it works so I try to continue with it.
Comment on attachment 646573 [details] [diff] [review]
change filter ui to checkboxes

IanN, mconley, can you look at the patch and see variable names like 'rdBfCl'. Are those OK or should they be more descriptive? rdBfCl probably represents 'ReceivedBeforeClassification'
Attachment #646573 - Flags: feedback?(iann_bugzilla)
Attachment #646573 - Flags: feedback?(mconley)
Attached patch WIP patch v2 (obsolete) — Splinter Review
So I updated the patch with these refinements:
- the new code should now produce the same values of the filter type (nsMsgFilterType) as current code. Uses .InboxRule instead of .Incoming.
- if server is defered, only disable the "After classification" radiobox instead of hiding it. The value will still be preserved if untouched so the user should see it.
- if all checkboxes are unchecked, force at least one to be checked, choosing the "manual" one.
- added Seamonkey strings

TODO:
- add accesskeys to the new labels
- implement the collapsing of the whole widget (if this is really wanted). It is planned to have at least 3 rows in the future (now it has 2).
Attachment #660240 - Flags: ui-review?(bwinton)
Attachment #660240 - Flags: feedback?(kent)
(For those not applying the patch but wanting to see how it looks like, see the screenshot in the URL field.)
Status: NEW → ASSIGNED
Bwinton, should I add the collapsing of the whole box after clicking a button? Something line in the Tools->Clear recent history dialog.

Also another question is if I should force the Manual Run to be checked if nothing else is, or I can allow all checkboxes to get unchecked but error out at an attempt to save/close the editor dialog.
Comment on attachment 646573 [details] [diff] [review]
change filter ui to checkboxes

Review of attachment 646573 [details] [diff] [review]:
-----------------------------------------------------------------

Hey xzer! Thanks for the patch!

Just put some general thoughts below. Let me know if you have any questions!

-Mike

::: mailnews/base/search/content/FilterEditor.js
@@ +53,5 @@
>        // deferred, (you must define them on the deferredTo server instead).
>        let server = gFilterList.folder.server;
> +      if(server.rootFolder != server.rootMsgFolder)
> +      {
> +        gFilterTypeDelegator.rdAfCl.style.display = "none";  

Instead of writing directly to the node's style, can you just set the collapsed attribute to true?

@@ +215,5 @@
> +}
> +
> +function initializeFilterTypeDelegator()
> +{
> +  gFilterTypeDelegator = {

If we remove the setTimeout's from init, is this still a delegator? If not, this should be renamed.

I think this object should be documented so we know exactly what it's doing and why.

@@ +216,5 @@
> +
> +function initializeFilterTypeDelegator()
> +{
> +  gFilterTypeDelegator = {
> +      ckMan : document.getElementById("ckManual"),

Yeah, these variable names are a little opaque. Could they be made more descriptive?

@@ +230,5 @@
> +      init : function()
> +      {
> +        //It seems that there is only this way can handle the event
> +        //of check status changing on both of mouse click and keyboard 
> +        //operation. Is there an another better way?

You should add an event listener for the "change" event, like this:

let checkbox = document.getElementById("some-checkbox");
checkbox.addEventListener("change", function(aEvent) {
  // Do whatever you'd like in here. You can read checkbox's checked status with
  // aEvent.target.checked. Or use the checkbox from the closure. Whichever.
});

@@ +299,5 @@
> +        
> +        this.click();
> +      },
> +      
> +      click : function(event)

I'd prefer if this was called "onClick". This is the function you should perhaps fire with your checkbox "changed" event listener.
Attachment #646573 - Flags: feedback?(mconley) → feedback-
Thanks mconley, but you have done overwork here :) I asked only for the variable names. If you see my WIP patch v2, most of the lines you object to no longer exist :)
Attached patch WIP patch v3 (obsolete) — Splinter Review
Like this better? :)
Attachment #660240 - Attachment is obsolete: true
Attachment #660240 - Flags: ui-review?(bwinton)
Attachment #660240 - Flags: feedback?(kent)
Attachment #660575 - Flags: ui-review?(bwinton)
Attachment #660575 - Flags: feedback?(mconley)
Attachment #660575 - Flags: feedback?(kent)
Maybe some tooltips could be added to the "classification" radios to explain what they mean?
Attachment #646573 - Attachment is obsolete: true
Attachment #646573 - Flags: feedback?(iann_bugzilla)
I believe a tooltip is absolutely needed because I had been asked many times for what the meaning of classification is from my sendfilter addon users.
Better yet, get rid of the user facing choice of classification, and just auto-detect if that's needed or not. This would also greatly simplify the UI. May be another bug though.
Blocks: 790876
Yes, it was already proposed in comment 2. But I am not able to do that so we split it into new bug 790876. rkent may look at it later.

I'll add some explanation tooltips for now.
(In reply to Magnus Melin from comment #31)
> Better yet, get rid of the user facing choice of classification, and just
> auto-detect if that's needed or not. This would also greatly simplify the
> UI. May be another bug though.

Yes I agree this is the plan.
Comment on attachment 660575 [details] [diff] [review]
WIP patch v3

> Bwinton, should I add the collapsing of the whole box after clicking a
> button? Something line in the Tools->Clear recent history dialog.

No, I think that would be too weird for just a couple of options.  (That dialog looks like that to match Firefox.)

> Also another question is if I should force the Manual Run to be checked
> if nothing else is, or I can allow all checkboxes to get unchecked but
> error out at an attempt to save/close the editor dialog.

After playing with it for a while, I don't think you should force the manual run to be checked, since it felt confusing, and if I accidentally unclick the "Checking Mail" then I need to go through way more steps to recover.

The other thing is that the layout feels a little odd to me.  I wonder if, instead of a pair of radio buttons, another control (like a checkbox) might be a better choice…  Or perhaps it should be
[] Manually Run
[] Checking Mail
  () Before Classification
  () After Classification

Oh, or:

[] Manually Run
[] Checking Mail [Before Classification|v]
                 [After Classification   ]

(with a drop-down.)  The tricky part with that would be to localize it, but hopefully we can make it not entirely ugly when not localized…

>+++ b/mail/locales/en-US/chrome/messenger/FilterEditor.dtd
>@@ -12,22 +12,25 @@
>+<!ENTITY contextBeforeCls.label "Before Classification">
>+<!ENTITY contextBeforeCls.accesskey "B">
>+<!ENTITY contextAfterCls.label "After Classification">
>+<!ENTITY contextAfterCls.accesskey "f">

How about "Before Junk Scanning", or "Before Junk Testing"?

Thanks,
Blake.
Attachment #660575 - Flags: ui-review?(bwinton) → ui-review-
(In reply to Blake Winton (:bwinton - Thunderbird UX) from comment #34)
> Comment on attachment 660575 [details] [diff] [review]
> WIP patch v3
> 
> > Bwinton, should I add the collapsing of the whole box after clicking a
> > button? Something line in the Tools->Clear recent history dialog.
> 
> No, I think that would be too weird for just a couple of options.  (That
> dialog looks like that to match Firefox.)
As said, there will be 3 rows of options in the future.

> > Also another question is if I should force the Manual Run to be checked
> > if nothing else is, or I can allow all checkboxes to get unchecked but
> > error out at an attempt to save/close the editor dialog.
> 
> After playing with it for a while, I don't think you should force the manual
> run to be checked, since it felt confusing, and if I accidentally unclick
> the "Checking Mail" then I need to go through way more steps to recover.
Ok, so I'll add the error message at save.

> The other thing is that the layout feels a little odd to me.  I wonder if,
> instead of a pair of radio buttons, another control (like a checkbox) might
> be a better choice…  Or perhaps it should be
> [] Manually Run
> [] Checking Mail
>   () Before Classification
>   () After Classification
That will be too high, even more considering the 3rd row that will be added in the future, that will have another suboptions too...

> Oh, or:
> [] Manually Run
> [] Checking Mail [Before Classification|v]
>                  [After Classification   ]
> 
> (with a drop-down.)  The tricky part with that would be to localize it, but
> hopefully we can make it not entirely ugly when not localized…
I don't see any localization difference in this and the original version with the radio's. What is the change here? Also, is it possible to disable an item in a dropdown? If yes, and the disabled item was previously selected, will it still be preserved if just opening the dropdown and not selecting anything?

> >+++ b/mail/locales/en-US/chrome/messenger/FilterEditor.dtd
> >@@ -12,22 +12,25 @@
> >+<!ENTITY contextBeforeCls.label "Before Classification">
> >+<!ENTITY contextBeforeCls.accesskey "B">
> >+<!ENTITY contextAfterCls.label "After Classification">
> >+<!ENTITY contextAfterCls.accesskey "f">
> 
> How about "Before Junk Scanning", or "Before Junk Testing"?
Depends on rkent if the classification really only contains junk scanning. It is called "afterPlugins" in the code, so maybe there are other operations hidden in there (like extension added actions).
Comment on attachment 660575 [details] [diff] [review]
WIP patch v3

Yes, I really like this! It will be very easy to add "Before Send" and "Before Archive" in the future.

The "classification" part is what is questioned by people. As I said, I think we should remove this completely before this feature ever hits a release, so I don't think we should put too much effort into that.

I did not review the code, just compiled it and looked at the results.
Attachment #660575 - Flags: feedback?(kent) → feedback+
(In reply to :aceman from comment #35)
> (In reply to Blake Winton (:bwinton - Thunderbird UX) from comment #34)
> > Comment on attachment 660575 [details] [diff] [review]
> > > Bwinton, should I add the collapsing of the whole box after clicking a
> > > button? Something line in the Tools->Clear recent history dialog.
> > No, I think that would be too weird for just a couple of options.  (That
> > dialog looks like that to match Firefox.)
> As said, there will be 3 rows of options in the future.

Even still.  That's not a lot of options.

> > The other thing is that the layout feels a little odd to me.  I wonder if,
> > instead of a pair of radio buttons, another control (like a checkbox) might
> > be a better choice…  Or perhaps it should be
> > [] Manually Run
> > [] Checking Mail
> >   () Before Classification
> >   () After Classification
> That will be too high, even more considering the 3rd row that will be added
> in the future, that will have another suboptions too...

So, it seems a little like you're asking me to review a UI that we haven't coded yet.  If you've got plans for what it will look like in the future, maybe you can post an image and I can review that?

> > Oh, or:
> > [] Manually Run
> > [] Checking Mail [Before Classification|v]
> >                  [After Classification   ]
> > (with a drop-down.)
> I don't see any localization difference in this and the original version
> with the radio's. What is the change here?

"Checking Mail After Classification" reads like a sentence.

> Also, is it possible to disable an item in a dropdown?
> If yes, and the disabled item was previously
> selected, will it still be preserved if just opening the dropdown and not
> selecting anything?

I believe so.  Can you check and let me know.

> > >+++ b/mail/locales/en-US/chrome/messenger/FilterEditor.dtd
> > >@@ -12,22 +12,25 @@
> > >+<!ENTITY contextBeforeCls.label "Before Classification">
> > >+<!ENTITY contextBeforeCls.accesskey "B">
> > >+<!ENTITY contextAfterCls.label "After Classification">
> > >+<!ENTITY contextAfterCls.accesskey "f">
> > How about "Before Junk Scanning", or "Before Junk Testing"?
> Depends on rkent if the classification really only contains junk scanning.
> It is called "afterPlugins" in the code, so maybe there are other operations
> hidden in there (like extension added actions).

It seems like we might be removing the classification part entirely, and just base it on what selections the user made in their filter settings.  (i.e. if they're asking for a junk score, automatically make it afterPlugins…)

Thanks,
Blake.
(In reply to Blake Winton (:bwinton - Thunderbird UX) from comment #37)
> (In reply to :aceman from comment #35)
> > (In reply to Blake Winton (:bwinton - Thunderbird UX) from comment #34)
> > > Comment on attachment 660575 [details] [diff] [review]
> > > > Bwinton, should I add the collapsing of the whole box after clicking a
> > > > button? Something line in the Tools->Clear recent history dialog.
> > > No, I think that would be too weird for just a couple of options.  (That
> > > dialog looks like that to match Firefox.)
> > As said, there will be 3 rows of options in the future.
> 
> Even still.  That's not a lot of options.

What about 4?

> > > The other thing is that the layout feels a little odd to me.  I wonder if,
> > > instead of a pair of radio buttons, another control (like a checkbox) might
> > > be a better choice…  Or perhaps it should be
> > > [] Manually Run
> > > [] Checking Mail
> > >   () Before Classification
> > >   () After Classification
> > That will be too high, even more considering the 3rd row that will be added
> > in the future, that will have another suboptions too...
> 
> So, it seems a little like you're asking me to review a UI that we haven't
> coded yet.  If you've got plans for what it will look like in the future,
> maybe you can post an image and I can review that?

I've mentioned the screenshot several times:
https://bugzilla.mozilla.org/attachment.cgi?id=423202

> > > >+++ b/mail/locales/en-US/chrome/messenger/FilterEditor.dtd
> > > >@@ -12,22 +12,25 @@
> > > >+<!ENTITY contextBeforeCls.label "Before Classification">
> > > >+<!ENTITY contextBeforeCls.accesskey "B">
> > > >+<!ENTITY contextAfterCls.label "After Classification">
> > > >+<!ENTITY contextAfterCls.accesskey "f">
> > > How about "Before Junk Scanning", or "Before Junk Testing"?
> > Depends on rkent if the classification really only contains junk scanning.
> > It is called "afterPlugins" in the code, so maybe there are other operations
> > hidden in there (like extension added actions).
> 
> It seems like we might be removing the classification part entirely, and
> just base it on what selections the user made in their filter settings. 
> (i.e. if they're asking for a junk score, automatically make it
> afterPlugins…)

Yes rkent plans to remove these "classification" options in a follow up bug before TB24, therefore it is not very productive to argue about the exact wording/position too much :)
Just a suggestion on how the flow could be visualized. the listboxes represent actions of what happens before (left) and after (right) the trigger; the checkboxes represent what triggers it. positions of the actions can be changed with the arrow buttons (or by double clicking an item)

I personally find this easier to see at a glance than lots of radio / checkboxes
I'll upload a new patch once bug 561762 is landed as there is a collision in code changes.
Depends on: 561762
Attached patch patch v4 (obsolete) — Splinter Review
Another try.
Attachment #660575 - Attachment is obsolete: true
Attachment #660575 - Flags: feedback?(mconley)
Attachment #666388 - Flags: ui-review?(bwinton)
Attachment #666388 - Flags: feedback?(kent)
Comment on attachment 666388 [details] [diff] [review]
patch v4

This is a giant improvement on what we have.  ui-r=me.

(I think we will want to be careful when we add more things in the future, but for now, this is awesome!)

Thanks,
Blake.
Attachment #666388 - Flags: ui-review?(bwinton) → ui-review+
Comment on attachment 666388 [details] [diff] [review]
patch v4

This looks great to me also!

(I did not review the code, just compiled it and tested it).
Attachment #666388 - Flags: feedback?(kent) → feedback+
rkent, great but who do we persuade to review it if not you? :)
Attachment #666388 - Attachment description: WIP patch v4 → patch v4
Attachment #666388 - Flags: review?(neil)
(In reply to :aceman from comment #44)
> rkent, great but who do we persuade to review it if not you? :)

I didn't say that I would not review the code, only that I had not. I just wanted to make it clear that your request was for feedback, so that is what I gave, and not review.
OK, understood:)
Comment on attachment 666388 [details] [diff] [review]
patch v4

>+      if (server.rootFolder != server.rootMsgFolder)
>+        gFilterTypeSelector.disableAfterPlugins();
So, this is to allow someone to fix their filter to run before plugins if they decide to defer their account?

>+    let nsMsgFilterType = Components.interfaces.nsMsgFilterType;
You use this a lot. Make this a global var/const perhaps?

>+  gFilterTypeSelector = {
>+      chkBoxManual: document.getElementById("runManual"),
Nit: incorrect indentation

>+      chkBoxIncoming : document.getElementById("runIncoming"),
Nit: "menulist", so why shorten "checkbox"?

>+        if (type & nsMsgFilterType.Manual)
>+          this.chkBoxManual.checked = true;
>+        else
>+          this.chkBoxManual.checked = false;
Nit: this.checkboxManual.checked = type & nsMsgFilterType.Manual;

>+          if (type & nsMsgFilterType.PostPlugin)
>+            this.menulistIncoming.selectedItem = this.menuitemAfterPlugins;
>+          else // type & nsMsgFilterType.Incoming
>+            this.menulistIncoming.selectedItem = this.menuitemBeforePlugins;
Could write this as this.menulistIncoming.selectedItem = type & nsMsgFilterType.PostPlugin ? this.menuitemAfterPlugins : this.menuitemBeforePlugins; which would allow you to write this.checkboxIncoming.checked = type & (nsMsgFilterType.PostPlugin | nsMsgFilterType.Incoming);

>+      /**
>+       * Enable the "before/after classification" menulist depending on
>+       * whether "run when incoming mail" is selected.
>+       */
>+      classificationState: function()
Even doEnabling() would be a better function name :-P

>-  var actionList = filter.actionList;
>-  var numActions = actionList.Count();
>+  let actionList = filter.actionList;
>+  let numActions = actionList.Count();
Must you really do these drive-by style changes?

>+            <menulist id="pluginsRunOrder"
>+                      command="cmd_updateFilterType"
>+                      disabled="true">
Does that actually do anything?

> <!ENTITY contextDesc.label "Apply filter when:">
>+<!ENTITY contextIncomingMail.label "Getting New Mail:">
>+<!ENTITY contextIncomingMail.accesskey "G">
> <!ENTITY contextManual.label "Manually Run">
>+<!ENTITY contextManual.accesskey "R">
>+<!ENTITY contextBeforeCls.label "Filter before Junk Classification">
>+<!ENTITY contextBeforeCls.accesskey "B">
>+<!ENTITY contextAfterCls.label "Filter after Junk Classification">
>+<!ENTITY contextAfterCls.accesskey "J">
I'm not a big fan of this wording but I forgot to look at what the plan is before doing the review...
(In reply to neil@parkwaycc.co.uk from comment #47)
> Comment on attachment 666388 [details] [diff] [review]
> patch v4
> 
> >+      if (server.rootFolder != server.rootMsgFolder)
> >+        gFilterTypeSelector.disableAfterPlugins();
> So, this is to allow someone to fix their filter to run before plugins if
> they decide to defer their account?
This does not change the current state of affairs. Do you propose anything better? On defered account a filter that is AfterPlugins would probably never run but it is valid. So we leave it as is. Just disable the item so that new filters are not created with it. Do you propose something else?

> >+    let nsMsgFilterType = Components.interfaces.nsMsgFilterType;
> You use this a lot. Make this a global var/const perhaps?
Ok, I'll make it a member of the gFilterTypeSelector.

> >-  var actionList = filter.actionList;
> >-  var numActions = actionList.Count();
> >+  let actionList = filter.actionList;
> >+  let numActions = actionList.Count();
> Must you really do these drive-by style changes?
NO:)

> 
> >+            <menulist id="pluginsRunOrder"
> >+                      command="cmd_updateFilterType"
> >+                      disabled="true">
> Does that actually do anything?
Should set recompute the type of filter when the menu selection changes. What do you mean?

> > <!ENTITY contextDesc.label "Apply filter when:">
> >+<!ENTITY contextIncomingMail.label "Getting New Mail:">
> >+<!ENTITY contextIncomingMail.accesskey "G">
> > <!ENTITY contextManual.label "Manually Run">
> >+<!ENTITY contextManual.accesskey "R">
> >+<!ENTITY contextBeforeCls.label "Filter before Junk Classification">
> >+<!ENTITY contextBeforeCls.accesskey "B">
> >+<!ENTITY contextAfterCls.label "Filter after Junk Classification">
> >+<!ENTITY contextAfterCls.accesskey "J">
> I'm not a big fan of this wording but I forgot to look at what the plan is
> before doing the review...

The plan is to kill the one global menulist and make it checkboxes to allow for many more events. The wording should not be worse than the original state. After much discussion it seems this wording is the best we could come up so far. Any proposals?
(In reply to aceman from comment #48)
> (In reply to comment #47)
> > (From update of attachment 666388 [details] [diff] [review])
> > >+    let nsMsgFilterType = Components.interfaces.nsMsgFilterType;
> > You use this a lot. Make this a global var/const perhaps?
> Ok, I'll make it a member of the gFilterTypeSelector.
Actually that's worse than what you've got now, so please don't.

> > >+            <menulist id="pluginsRunOrder"
> > >+                      command="cmd_updateFilterType"
> > >+                      disabled="true">
> > Does that actually do anything?
> What do you mean?
I mean, what is the point of the disabled="true" attribute?
The menu is initially disabled until a call to .setType enables it as needed.
So it is basically a safety measure - disable it until we decide what state it should be in. Yes, the state is decided in *onLoad() so there is only a small timeframe. I'll remove it if you think it is superfluous.
Attached patch patch v5 (obsolete) — Splinter Review
Attachment #666388 - Attachment is obsolete: true
Attachment #666388 - Flags: review?(neil)
Attachment #668778 - Flags: review?(neil)
Comment on attachment 668778 [details] [diff] [review]
patch v5

>+function initializeFilterTypeSelector()
>+{
>+  /**
>+   * This object controls code interaction with the widget allowing specifying
>+   * the filter type (event when the filter is run).
>+   */
>+  gFilterTypeSelector = {
>+    checkBoxManual: document.getElementById("runManual"),
>+    checkBoxIncoming : document.getElementById("runIncoming"),
>+
>+    menulistIncoming: document.getElementById("pluginsRunOrder"),
>+
>+    menuitemBeforePlugins: document.getElementById("runBeforePlugins"),
>+    menuitemAfterPlugins: document.getElementById("runAfterPlugins"),
[I wish this could be a global but then you get the problem of when do you get the element references.]

>+      if (this.checkBoxManual.checked) {
>+          type |= nsMsgFilterType.Manual;
>+      }
>+
>+      if (this.checkBoxIncoming.checked) {
>+        if (this.menulistIncoming.selectedItem == this.menuitemAfterPlugins) {
>+            type |= nsMsgFilterType.PostPlugin;
[A couple of lines have slightly unusual indentation.]

>   <separator/>
[This separator seems somewhat useless now.]

>+            <menulist id="pluginsRunOrder"
>+                      command="cmd_updateFilterType">
>+              <menupopup>
>+                <menuitem id="runBeforePlugins"
>+                          label="&contextBeforeCls.label;"
>+                          accesskey="&contextBeforeCls.accesskey;"/>
>+                <menuitem id="runAfterPlugins"
>+                          label="&contextAfterCls.label;"
>+                          accesskey="&contextAfterCls.accesskey;"/>
[It's unusual to have accesskeys in menulist menuitems.]

> <!ENTITY contextDesc.label "Apply filter when:">
[This used to be a <label> but a <caption> generally doesn't end in a colon.]
Attachment #668778 - Flags: review?(neil) → review+
Attached patch patch v6 (obsolete) — Splinter Review
Thanks.
Attachment #668778 - Attachment is obsolete: true
Attachment #668947 - Flags: review?(kent)
Is this meant to allow triggering/running filters on tag assignment?
(In reply to klonos from comment #55)
> Is this meant to allow triggering/running filters on tag assignment?

This bug is a preparation for subsequent enhancements that could add more complex filter triggers without the combinatorial explosion of the existing UI. Tag assignment would be an example, though I am not aware of previous discussions of that. On send, on a time schedule, and on archive are the more obvious candidates.
Comment on attachment 668947 [details] [diff] [review]
patch v6

Review of attachment 668947 [details] [diff] [review]:
-----------------------------------------------------------------

OK this looks good to me with just a couple of minor nits - but if you think I am imposing my personal taste feel free to land it as is.

::: mailnews/base/search/content/FilterEditor.js
@@ +264,5 @@
> +    /**
> +     * Sets the checkboxes to represent the filter type passed in.
> +     *
> +     * @param aType  the filter type to set in terms
> +     *              of Components.interfaces.nsMsgFilterType values.

Nit: alignment off by one

@@ +275,5 @@
> +
> +      this.checkBoxManual.checked = aType & nsMsgFilterType.Manual;
> +
> +      this.checkBoxIncoming.checked = aType & (nsMsgFilterType.PostPlugin |
> +                                              nsMsgFilterType.Incoming);

Nit: align the two nsMsgFilterType lines
Attachment #668947 - Flags: review?(kent) → review+
Attached patch patch v7Splinter Review
Thanks.
Attachment #668947 - Attachment is obsolete: true
Attachment #672824 - Flags: review+
Keywords: checkin-needed
https://hg.mozilla.org/comm-central/rev/75f636a2c533
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Flags: in-testsuite-
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 19.0
You need to log in before you can comment on or make changes to this bug.