67161 - Need `progress' type for windows

Status: NEW

(Core :: XUL, enhancement)

Description

[Matthew T (active 1999-2002)]

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.

Comment 1

[Peter Lairo]

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.

Comment 2

[Matthew T (active 1999-2002)]

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. :-)

Comment 3

[Peter Lairo]

I trust you, baby ;)

I just hope then that your list of *six different kinds of window* is complete.

Comment 4

[Deven Corzine]

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...

Comment 5

[Tim Powell]

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.

Comment 6

[timeless]

you're right. they should be closable on windows.

Comment 7

[Peter Trudelle]

->danm, for future consideration

Comment 8

[Matthew T (active 1999-2002)]

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.

Comment 9

[Ryan Massie]

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. 

Comment 10

[timeless]

since Yes and No are hard to understand, Escape and X [close] should always 
allow one to select the cancel event, whichever that is.

Comment 11

[Håkan Waara]

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

Comment 12

[James Ross]

cc'ing to self as bug blocks other interesting bugs.

Comment 13

[Arthur]

Cc'ing myself. IMO Target Milestone should be mozilla0.9.2 and certainly not 
"future" as it blocks quite a few annoying bugs.

Comment 14

[:deanis74]

Didn't the fix for bug 26029, with the "minimizable" window essentially give the 
progress window?

Comment 15

[Matthew T (active 1999-2002)]

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