50521 - Close box should not be present in modal dialogs

Status: RESOLVED EXPIRED

(SeaMonkey :: UI Design, defect, P3)

Description

[Matthew T (active 1999-2002)]

This came up in bug 22049 and bug 50097.

Modal dialog boxes on Mac OS do not have a close box. This is because modal 
dialog boxes require the user to make a decision, by selecting one of the command 
buttons in the dialog (e.g. `Yes', `No', `Delete', `Save', `Finish'). Supplying a 
close box would mislead the user into thinking that they do not have to make a 
decision, when really they do.

The lack of a close box also acts as a helpful visual cue that the dialog is a 
modal one.

On Windows, modal dialog boxes do have a close box, which when clicked behaves 
the same as a `Cancel' button -- if the dialog actually contains a `Cancel' 
button to begin with. The Microsoft UI guidelines <http://msdn.microsoft.com/
library/default.asp?URL=/library/books/winguide/ch09f.htm> say that you should 
`Enable the title bar Close box only if the message includes a Cancel button. 
Otherwise, the meaning of the Close operation may be ambiguous.'

And here's the catch: you don't know, when you create a modal dialog for 
XPToolkit, whether or not it is going to contain a `Cancel' button.

Even if you could determine this ahead of time, that doesn't mean it's a good 
idea. I have often seen Windows users repeatedly close, and cause to be reopened 
soon after, the same modal dialog -- because it had a close box, which they used 
to close the dialog immediately instead of actually reading what the dialog said 
(and taking a course of action such that the dialog did not have to reappear).

So, I suggest that modal dialogs on Windows have their close boxes removed. This 
would have the following benefits:
* bugs like bug 50097 would no longer happen, because Mozilla developers (even
  those who don't try their code on Macs) would be aware that a modal XPToolkit
  dialog must supply an intra-dialog means of closing itself;
* XPToolkit apps which purport to work cross-platform, but which have not been
  tested by the author of the app on a Mac, won't contain uncloseable dialogs
  when run on Mac OS, because the Windows modal dialogs will work the same way
  (so the author will be aware of the need to provide a means of closing the
  dialog);
* Windows users will benefit from the visual hint (the lack of a close box) that
  a modal dialog is modal.

Comment 1

[hangas]

Nominating for nsbeta3 and sending to component owner

Comment 2

[John Morrison]

While Matthew raises an interesting but debatable point, given that we have 
three weeks left in the current cycle and a lot of more pressing needs, that
we are already consistent with platform conventions on mac (no close), linux 
(has close), win32 (has close), and that this is really feature work ... 
->Future/nsbeta3- (unless Peter shocks the heck out of me ...)

Comment 3

[Peter Trudelle]

accepting for future (no shock there!)

Comment 4

[Peter Trudelle]

->danm, untargetted

Comment 5

[Dan M]

Toolkit allows you to open windows without close boxes, so if apps wants to
remove all close boxes from the alert windows on all platforms, this would do it

Index: embedding/components/windowwatcher/src/nsPromptService.cpp
===================================================================
RCS file:
/cvsroot/mozilla/embedding/components/windowwatcher/src/nsPromptService.cpp,v
retrieving revision 1.18
diff -u -r1.18 nsPromptService.cpp
--- nsPromptService.cpp	2001/09/25 22:58:22	1.18
+++ nsPromptService.cpp	2001/10/11 03:37:58
@@ -625,7 +625,7 @@
   nsCOMPtr<nsISupports> arguments(do_QueryInterface(aParamBlock));
   nsCOMPtr<nsIDOMWindow> dialog;
   rv = mWatcher->OpenWindow(aParent, aChromeURL, "_blank",
-                            "centerscreen,chrome,modal,titlebar", arguments,
+                   "centerscreen,chrome,modal,titlebar,close=no", arguments,
                             getter_AddRefs(dialog));
 
   return rv;

At this point it becomes a design issue. Reassigning to apps.

Comment 6

[Peter Trudelle]

->xpapps

Comment 7

[Peter Trudelle]

developer can choose to have a close box or not, marking wontfix

Comment 8

[Jesse Ruderman]

The close box absent by default on Mac.  We shouldn't make it any harder for 
Mozilla-based apps to conform to Mac ui conventions (when running on Mac) than 
we have to.

Comment 9

[Andrew Thompson]

Agreed. Resummarizing

Comment 10

[John Morrison]

Great idea. Consider it done. Long ago. There is no close widget on Mac modal 
window by default, right?

Comment 11

[Andrew Thompson]

yes. apologies. don't edit bugs when tired.

Comment 12

[sairuh (rarely reading bugmail)]

mass verification of WorksForMe bugs: to find all bugspam pertaining to this,
set your search string to "IfItWorksForSlappyTheSquirrelThenItWFM".

if you think this particular bug is *still* an open issue, please make sure of
the following before reopening:

a. that it's still a problem with ***recent trunk builds*** on the all
appropriate platform[s]

b. provide clear steps to reproduce (unless a good test case is already in the
bug report), making sure it pertains to the original problem (avoid morphing as
much as possible :)

Comment 13

[Matthew T (active 1999-2002)]

Reproduced in build 2002021303, Windows 2000 -- and, I assume, on Windows 98 
where I originally filed it. Undoing damage caused by [e-mail], and 
reopening.

Trudelle is incorrect: there is no way someone using nsIPrompt can specify 
whether the alert has a close box or not. And nor should it be possible to 
include a close box in any modal dialog, since it would be impossible on some 
platforms (Mac OS 8/9/X) for such a potentially critical setting to be heeded. 
Removing the close box in nsIPrompt would fix some of this bug, but ignoring 
the `close' flag when the `modal' flag is present would fix all of it.

Comment 14

[Hixie (not reading bugmail)]

Fixing bitrot caused by the bug being reopened.

Comment 15

[Prognathous]

Is this change also requested for Windows dialogs that do have a Cancel button?

Prog.

Comment 16

[Matthew T (active 1999-2002)]

Yes. See "Even if you could determine this ahead of time ..." in comment 0.

Comment 17

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 18

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 19

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 20

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 21

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 22

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 23

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 24

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420