Using may24 m16 commercial build I am not certain what is proper behavior in this case, but I'm logging it as an issue because this is not consistent with 4.x behavior. Will cc jglick for an added opinion. When you add a new filter or edit an existing one and confirm OK from the filter rules subdialog then Cancel from the main/parent message filters dialog, the changes to the filters (edited or newly created) are kept intact. In this same situation, 4.x will discard the changes. Steps: 1. From 3-pane mail window, launch Message Filters (Edit|Message Filters). 2. From Message Filters dialog, click New to open filter rules subdialog. 3. Add a simple filter and confirm OK from the filter rules subdialog. 4. You are returned to the main message filters dialog and the newly added filter appears in the filter list. 5. Click Cancel button from the main filter dialog, dialog closes. 6. Launch message filters again and see the newly created filter is still present in the list. 7. Repeat process, but edit an existing filter rather than create a new one. Same end result. Result: Cancel from main filters dialog after adding new or editing existing filters retains the (confirmed) filter changes. Expected result (comparing to 4.x behavior): Cancel from main filters dialog will discard any (confirmed) filter changes. Note: 4.x filter ui in Mac differs from that on Unix or Win32 platforms. The behavior I noted is with Unix & win32.

yeah, I wondered what to do about this. I might make cancel re-load the filters from disk or something.

Even MS can't do this one consistently. In the OS Display properties dialogs they do it how SeaMonkey is currently working. In MS Word, they do it how 4.x worked. In 4.x for the Mac, we don't have this problem for the Filters UI, but for the search UI, we do it the way Seamonkey is currently working. For discussion sake: Message Filters dialog - parent dialog Filter Rules dialog - child dialog I can see both sides to this one. On the one hand, they are TWO separate dialogs. When the user "OK"'s the child dialog, they are accepting their actions. So, canceling the parent dialog would only apply to changes that they made on the parent dialog. On the other hand, since the child dialog is a sub of the parent, users may think all actions (including those on the child dialog) are canceled when they cancel the parent dialog. Or we could change the "Cancel" to "Close" on the parent dialog? cc'ing the UI folks to see if we can get a general agreement. This isn't a huge deal, but which ever way we go, all SeaMonkey apps should work the same way.

I think the best solution for now would be to just have a "Close" button instead of ok/cancel.

OK, I agree with Brendan. Lets do this the 4.x way. OK and Cancel on both dialogs. Cancel on the parent dialog will also cancel any actions done on the child dialog. Brendan Donohoe wrote: The way I see it, there's nothing to discuss here. Cancelling a dialog (modal or modeless) clears *all* changes within it, no matter how those changes were made (and as always, despite Microsoft's inability to do *anything* consistently). That's the whole point of cancel. If there's any reason not to have the ability to back out of such changes (and I don't know why there would be except that Microsoft started a trend in this direction), then Okay and Cancel should be replaced by a single Close which has no bearing on committing changes since changes will be committed elsewhere.

that's nice and all but its a tremendous amount of work that won't happen anytime we have any other more important issues (read: never)

never = future :)

Adding myself to cc: list.

reassigning my filter bugs to gayatrib..

Come on now, jglick, can't we do the "Close" solution for this?

OK, lets go with "Close" on the Message Filters dialog. This is how this dialog is currently behaving (Cancel works like Close) and the UI should reflect that (until/if this is ever changed).

What's with this `come on now' business? Cajoling Jennifer into supporting terrible UI? Dear me. If you can't distinguish between cancelling (`Cancel') and confirming (`OK') the operations, then don't have the buttons at all. Just have a close box in the window chrome. Note that this is basically a duplicate of bug 42090, or vice versa.

reassigning to naving

agreed, it's a dup. *** This bug has been marked as a duplicate of 42090 ***

verified as duplicate