Closed Bug 50521 Opened 21 years ago Closed 11 years ago

Close box should not be present in modal dialogs

Categories

(SeaMonkey :: UI Design, defect, P3)

x86
Windows 98
defect

Tracking

(Not tracked)

RESOLVED EXPIRED
Future

People

(Reporter: mpt, Assigned: trudelle)

Details

(Keywords: helpwanted, Whiteboard: [Hixie-P0])

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.
Nominating for nsbeta3 and sending to component owner
Assignee: hangas → trudelle
Component: User Interface: Design Feedback → XP Toolkit/Widgets
Keywords: nsbeta3
QA Contact: mpt → jrgm
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 ...)
Whiteboard: [nsbeta3-]
Target Milestone: --- → Future
Status: NEW → ASSIGNED
accepting for future (no shock there!)
->danm, untargetted
Assignee: trudelle → danm
Status: ASSIGNED → NEW
Target Milestone: Future → ---
Target Milestone: --- → Future
Keywords: nsbeta3helpwanted
Whiteboard: [nsbeta3-]
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.
Assignee: danm → trudelle
Target Milestone: Future → ---
->xpapps
Assignee: trudelle → pchen
Component: XP Toolkit/Widgets → XP Apps
QA Contact: jrgm → sairuh
developer can choose to have a close box or not, marking wontfix
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WONTFIX
Target Milestone: --- → Future
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.
Agreed. Resummarizing
Status: RESOLVED → REOPENED
OS: Windows 98 → Mac System 8.5
Hardware: PC → Macintosh
Resolution: WONTFIX → ---
Summary: Close box should not be present in modal dialogs → Close box should not be present by default in modal dialogs on Mac OS
Great idea. Consider it done. Long ago. There is no close widget on Mac modal 
window by default, right?
Status: REOPENED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → WORKSFORME
yes. apologies. don't edit bugs when tired.
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 :)
Status: RESOLVED → VERIFIED
Reproduced in build 2002021303, Windows 2000 -- and, I assume, on Windows 98 
where I originally filed it. Undoing damage caused by lordpixel@mac.com, 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.
Status: VERIFIED → REOPENED
OS: Mac System 8.5 → Windows 98
Hardware: Macintosh → PC
Resolution: WORKSFORME → ---
Summary: Close box should not be present by default in modal dialogs on Mac OS → Close box should not be present in modal dialogs
Fixing bitrot caused by the bug being reopened.
Assignee: pchen → trudelle
Status: REOPENED → NEW
Whiteboard: [Hixie-P0]
Target Milestone: Future → ---
Target Milestone: --- → Future
Product: Core → Mozilla Application Suite
Is this change also requested for Windows dialogs that do have a Cancel button?

Prog.
Yes. See "Even if you could determine this ahead of time ..." in comment 0.
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
Status: NEW → UNCONFIRMED
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
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
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
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
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
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
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
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago11 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.