Closed Bug 50097 Opened 24 years ago Closed 24 years ago

`Understanding Privacy' modal dialog can't be closed

Categories

(SeaMonkey :: UI Design, defect, P3)

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: mpt, Assigned: bugzilla)

Details

Build: 2000082313, Mac OS 9.0

To reproduce:
* Start Mozilla.
* Open the Preferences dialog.
* Open the `Cookies' category.
* Click the `Understanding Privacy' button.
* Try to do anything else.

What happens:
* You can't.

The `Understanding Privacy' window is modal, and does not have a close box or a 
`Done' button. So the only way to get out, once you have opened the window, is to 
force-quit Mozilla.
What?  You mean there is no x to click on in the upper right corner like there 
is for unix and win32?
Status: NEW → ASSIGNED
Keywords: nsbeta3
Target Milestone: --- → M18
Confirmed in Mac M18-2000-08-23-04
The window has a scroll bar but nothing else for control.
command+W does not close the window either.
What an idiotic platform the mac is. :-(

OK, added an OK button to the window.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Steve, modal dialogs should never have close boxes, no matter what the platform. 
Modal dialogs require the user to make a decision; giving them a close box gives 
the illusion that the user does not have to make a decision when really they do
-- it is the apparent equivalent of an `I Don't Know' button.

So if this window now has *both* a close box *and* an `Ok' button on Windows and 
X, you've just fixed a bug on one platform by introducing a bug on two others.

I see no reason for the `Understanding Privacy' window needing to be modal; so 
perhaps you should make it a non-modal window instead.
I don't understand your objection.  Furthermore, making it a non-modal dialog 
does solve the mac problem -- the mac user still has no way of ever dismissing 
it unless it has a button for him to press.
I think he was thinking that it would be a non-model dialog box with a 
close box for people to close it. There is really no reason for it to be a 
model dialog box. If we are going to change this, then we should reopen 
the bug.
looking at 2000.08.25.0x bits:

* Mac OS 9.0: this dialog now has a Close button, but no X closing widget. it
behaves modally.

* linux and winNT: this dialog now has *both* a Close button and an X. this also
behaves modally --although i can close it by clicking the X (i shouldn't since
the X shouldn't even be there)

yes, modal dialogs should not have that X widget. reopening.

Status: RESOLVED → REOPENED
Hardware: Macintosh → All
Resolution: FIXED → ---
I'm worried that modality conflicts might be introduced if we try to launch a 
non-modal child from a modal parent.  I'll give it a shot and see what happens.
hmm, it didn't introduce any problems as I had expected (guess danm fixed that).

reassigning to me while I test if the solution is sufficient XP-wise
Assignee: morse → BlakeR1234
Status: REOPENED → NEW
I don't understand sarah's comment.  All my other modal dialogs (cookie viewer, 
signon viewer, wallet editor, wallet previewer) have the X widget.  Should they 
all be changed?  :-(
And so does every other modal dialog.  The open-web-location for example.  
Surely you are not saying that we need to remove the x-widget from all of them.
steve: thx for pointing that out... bluh.

jrgm, do you know of an existing (more generic) bug which points this UI issue
out, ie, that modal dialogs (on linux and win32, eg, open web location) also
have the X close widget. seems like a long-standing issue that we might've been
going back and forth on.

but, back to this bug: i've tested blake's patch to set ViewTutorial() to
modal=no. looks fine to me. which seems to be the easy solution here.
Yeah, I just noticed that all modal dialogs (even alert()'s and confirm()'s) 
have the close button enabled.  So instead of each individual modal dialog 
owner trying to disable the button, I'm going to file a new bug proposing that 
we disable this close button when the style of a window is modal (perhaps we 
could do this disabling when we use each platform's API to specify modality in 
the dialogs)

For now (since that likely won't be fixed for 6.0), I'm going to make this 
dialog non-modal.  This makes sense anyways, since people might want to read 
this tutorial/information while they're actually trying out the feature.  Is 
this an acceptable solution for everyone?
Status: NEW → ASSIGNED
Modal dialogs on linux and windows typically do have a Close control (X). 
Matthew makes an interesting point above, although as the saying goes "'No
decision' _is_ a decision". 

At any rate, there is no point in doing the work to remove (x) from modal
dialogs on those platforms where the convention is that modal dialogs have a
close widget. 

If the 'Understanding Privacy' dialog can be closed on all three platforms
then this bug is FIXED. (Subsidiary issues should be filed as separate bugs
[or RFE's as the case may be]). 
What should happen is that the Windows widget code needs to be more faithful to 
the chrome dialog flags. I fixed Mac to be, and immediately found a bunch of 
dialogs that were missing "titlebar".
John's right.  Modal dialogs on win32 still have enabled X buttons.  I thought 
otherwise because I was looking at message boxes, which apparently don't (their 
X buttons are enabled).  The patch I had anyways doesn't work on Mac (only 
Linux and win32, for whatever reason).  Closing this one out, new bugs can be 
filed for all these other issues.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
vrfying........
Status: RESOLVED → VERIFIED
Just for fun, filed bug 50521 on the general modal dialog close box issue.
Product: Core → Mozilla Application Suite
OS: All
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.