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": [] movable [] modal [] closable [] minimizable [] 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 windows). 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 box fit? 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 progress window?

No -- see bug 76110 and bug 76122. And unlike dialogs, progress windows should not be modal.