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)

defect

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 42090
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.
QA Contact: lchiang → laurel
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.
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 :)
Target Milestone: M18 → Future
Adding myself to cc: list.
reassigning my filter bugs to gayatrib..
Assignee: alecf → gayatrib
Status: ASSIGNED → NEW
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
Assignee: gayatrib → naving
agreed, it's a dup.

*** This bug has been marked as a duplicate of 42090 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
verified as duplicate
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.