Closed
Bug 40512
Opened 24 years ago
Closed 23 years ago
Filter UI: Cancel from main dialog keeps edits (differs from 4.x)
Categories
(MailNews Core :: Filters, defect, P3)
MailNews Core
Filters
Tracking
(Not tracked)
Future
People
(Reporter: laurel, Assigned: naving)
Details
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.
Comment 1•24 years ago
|
||
yeah, I wondered what to do about this. I might make cancel re-load the filters from disk or something.
Status: NEW → ASSIGNED
Target Milestone: --- → M18
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.
Comment 3•24 years ago
|
||
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.
Comment 5•24 years ago
|
||
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)
Comment 8•24 years ago
|
||
reassigning my filter bugs to gayatrib..
Assignee: alecf → gayatrib
Status: ASSIGNED → NEW
Comment 9•23 years ago
|
||
Come on now, jglick, can't we do the "Close" solution for this?
Comment 10•23 years ago
|
||
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).
Comment 11•23 years ago
|
||
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.
Comment 13•23 years ago
|
||
agreed, it's a dup. *** This bug has been marked as a duplicate of 42090 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•