Bug 1653690 Comment 5 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

I think the behavior is due to
https://searchfox.org/comm-central/source/mailnews/base/search/src/nsMsgFilterService.cpp#749
```
        case nsMsgFilterAction::CopyToFolder: {
          nsCString uri;
          curFolder->GetURI(uri);
          BREAK_ACTION_IF_FALSE(!uri.Equals(actionTargetFolderUri),   <=== This
                                "Target folder is the same as source folder");

```

Instead of making it an error (BREAK_ACTION_IF_FALSE), it would be neat if we can simply CONTINUE (because this is a NOOP) after possibly logging this.
I am not sure if there is an appropriate macro near the beginning of the file. If I am not mistaken, "COTINUE_..." macro seems to pop up a dialog(?).

Introduced in Bug 1547508 (?)

To reiterate, I have a large number of filters which include filters  that set attribute of a matching message such as "this is not a spam" and move it into "Inbox".
Before TB78, I could apply the whole set of filters on "Inbox" without an issue. I could start the filtering and went for a cup of coffee and done with it. (My Inbox is always large and the # of  filters is large.) 
Now, TB78 complains due to the same identitty of source/destination folder and the processing stops with modal dialog for each such filter, and until I click the dialog, the processing does not continue. Bad.

Please note that the whole set of filters can be applied to a different folder, i.e., not "Inbox",  (quite likely imported from elsewhere), and in the case of newly imported folder with a newly created name, the whole filter runs uninterrupted without being stopped by unwanted dialog.
Thus, applying the same set of filters (as a whole) is a great way to import and filter new messages from elsewhere.

I wonder if the line mentioned above can be modified to continue with possibly a suitable logging BUT WITHOUT the modal dialog.
If a popup is just for notification and does not block the processing to continue, I can live with it (hmm, maybe).
I think the behavior is due to
https://searchfox.org/comm-central/source/mailnews/base/search/src/nsMsgFilterService.cpp#749
```
        case nsMsgFilterAction::CopyToFolder: {
          nsCString uri;
          curFolder->GetURI(uri);
          BREAK_ACTION_IF_FALSE(!uri.Equals(actionTargetFolderUri),   <=== This
                                "Target folder is the same as source folder");

```

Instead of making it an error (BREAK_ACTION_IF_FALSE), it would be neat if we can simply CONTINUE (because this is a NOOP) after possibly logging this.
I am not sure if there is an appropriate macro near the beginning of the file. If I am not mistaken, "COTINUE_..." macro seems to pop up a dialog(?).

Introduced in Bug 1547508 (?)

To reiterate, I have a large number of filters which include filters  that set attribute of a matching message such as "this is not a spam" and move it into "Inbox".
Before TB78, I could apply the whole set of filters on "Inbox" without an issue. I could start the filtering and went for a cup of coffee and done with it. (My Inbox is always large and the # of  filters is large.) 
Now, TB78 complains due to the same identitty of source/destination folder and the processing stops with modal dialog for each such filter, and until I click the dialog, the processing does not continue. Bad.

Please note that the whole set of filters can be applied to a different folder, i.e., not "Inbox",  (quite likely imported from elsewhere), and in the case of newly imported folder with a newly created name, the whole filter runs uninterrupted without being stopped by unwanted dialog.
Thus, applying the same set of filters (as a whole) is a great way to import and filter new messages from elsewhere. (One reason why setting an attribute of a message and moving it "Inbox" in some filters.)

I wonder if the source line mentioned above can be modified to continue with possibly a suitable logging BUT WITHOUT the modal dialog.
If a popup is just for notification and does not block the processing to continue, I can live with it (hmm, maybe).
I think the behavior is due to
https://searchfox.org/comm-central/source/mailnews/base/search/src/nsMsgFilterService.cpp#749
```
        case nsMsgFilterAction::CopyToFolder: {
          nsCString uri;
          curFolder->GetURI(uri);
          BREAK_ACTION_IF_FALSE(!uri.Equals(actionTargetFolderUri),   <=== This
                                "Target folder is the same as source folder");

```

Instead of making it an error (BREAK_ACTION_IF_FALSE), it would be neat if we can simply CONTINUE (because this is a NOOP) after possibly logging this.
I am not sure if there is an appropriate macro near the beginning of the file. If I am not mistaken, "COTINUE_..." macro seems to pop up a dialog(?).

Introduced in Bug 1547508 (?)

To reiterate, I have a large number of filters which include filters  that set attribute of a matching message such as "this is not a spam" and move it into "Inbox".
Before TB78, I could apply the whole set of filters on "Inbox" without an issue. I could start the filtering and went for a cup of coffee and done with it. (My Inbox is always large and the # of  filters is large.) 
Now, TB78 complains due to the same identity of source/destination folder and the processing stops with modal dialog for each such filter, and until I click the dialog, the processing does not continue. Bad.

Please note that the whole set of filters can be applied to a different folder, i.e., not "Inbox",  (quite likely imported from elsewhere), and in the case of newly imported folder with a newly created name, the whole filter runs uninterrupted without being stopped by unwanted dialog.
Thus, applying the same set of filters (as a whole) is a great way to import and filter new messages from elsewhere. (One reason why setting an attribute of a message and moving it "Inbox" in some filters.)

I wonder if the source line mentioned above can be modified to continue with possibly a suitable logging BUT WITHOUT the modal dialog.
If a popup is just for notification and does not block the processing to continue, I can live with it (hmm, maybe).

Back to Bug 1653690 Comment 5