XP Toolkit needs six different kinds of window:
(1) popups (not movable, not modal, not closable, not minimizable, not resizable
by default, no chrome);
(2) document windows (movable, not modal, closable, minimizable, resizable by
default, ordinary chrome);
(3) dialogs (movable, modal, not closable, not minimizable, not resizable by
default, ordinary chrome);
(4) alerts (movable, modal, not closable, not minimizable, not resizable by
default, alert chrome, comes with optional standard overlay for position of
icon and position/ordering of buttons);
(5) progress windows (movable, not modal, not closable, minimizable, not
resizable by default, ordinary chrome);
(6) assistant windows (movable, not modal, not closable on Windows, closable on
other platforms, not minimizable, not resizable by default, ordinary chrome,
comes with free platform-specific overlay for position of banner and
position/assortment of buttons).
Currently we appear to have only the first three of these, and the lack of the
latter three is causing numerous undesirable results in Mozilla's UI.
This bug in particular requests the implementation of (5), the `progress' kind of
window. Two examples of where this is needed:
* the download progress window should be minimizable but is not, because it is
a dialog when it should be a progress window;
* the `Migrating Profile' progress window should not be closable or resizable
but is, because it is a document window when it should be a progress window.
Although these are nice general categories that might cover the majority of
situations, wouldn't it be easier to have a separately settable setting and let
the creator of the window decide what setting(s) his window should have?
e.g. "Window that does something":
 resizable by default
 no chrome
This would be far more flexible.
No, because that would just encourage developers to make mistakes. Mistakes like
trying to give alerts close boxes when Mac OS (for good reason) doesn't allow
that (Mozilla has already had a couple of `hang' bugs caused by developers doing
that). Or like unintentionally locking up a user's computer by making a large
modal dialog with no chrome (which means no title bar, and no way to get to other
I've thought a lot about this bug, trust me. :-)
I trust you, baby ;)
I just hope then that your list of *six different kinds of window* is complete.
How about both? Make the 6 window types, implemented by calling a generic
flexible implementation function. New window types could then easily be added
(calling the generic function), but only the code for specific window types
should call the generic function. (Possibly make it private.) Then if there's
a 7th window type that hasn't come to mind, adding it becomes trivial...
I don't see why dialogs and progress windows should be not closable. (I'm not
sure what that means.) I'm assuming you mean that they shouldn't have the close
button (X in top right corner of window)?
On Windows at least, Nav4 and IE5 progress windows (such as download progress)
are closable. Windows dialogs also often have the close button. Windows alerts
also have the close button.
Can you give specific examples of each type? For example, where does the Find
I agree that having specific window types will help avoid errors.
you're right. they should be closable on windows.
->danm, for future consideration
The six types I listed are those which XP Toolkit *needs*; other types -- such
as windoids, which could be used for floating palettes etc -- fall into the
`nice to have' category.
Giving a dialog a close button is a bad idea, because it misleads the user into
thinking that they do not have to make a decision when really they do, so the
meaning of the close button is ambiguous -- what would a close button mean in
`Do you want to discard changes? ( Yes ) ( No )'? (The Windows UI guidelines
describe a close box for dialogs as `optional', probably because Microsoft
haven't yet removed it from all the dialogs in their own software.) Similarly,
giving a progress window a close button is a bad idea, because its meaning
would be ambiguous -- does it cancel the operation in progress, or does it just
hide the progress of the operation?
Specific examples of each type:
* popups: tooltips, help balloons
* document windows: browser windows, search results
* dialogs: Open Location dialog, Find in This Page dialog
* alerts: error messages, save-before-closing confirmation, cookie alerts
* progress windows: sending mail progress, file download progress
* assistant windows: New Profile Wizard, Account Wizard.
Typically when there is a close button on a progress window, there is only one
other button on the window, like cancel. I assumed that the close button took
on the function of the only other option on the window. In fact, I can't think
of any other function used in this situation other than cancel. Either way, it
dosen't really matter that much. I do agree that the function of the close
button becomes ambiguous in a yes/no dialog and it shouldn't be on there.
since Yes and No are hard to understand, Escape and X [close] should always
allow one to select the cancel event, whichever that is.
There is quite some bugs that are all blocked by this one. And some of those, is
blocking other bugs.. etc.
I think this bug should have a somewhat high priority. Nominating for mozilla1.0
cc'ing to self as bug blocks other interesting bugs.
Cc'ing myself. IMO Target Milestone should be mozilla0.9.2 and certainly not
"future" as it blocks quite a few annoying bugs.
Didn't the fix for bug 26029, with the "minimizable" window essentially give the
No -- see bug 76110 and bug 76122. And unlike dialogs, progress windows should
not be modal.