Closed
Bug 40700
Opened 25 years ago
Closed 4 years ago
Platform-consistent look and feel for alert boxes
Categories
(Core :: XUL, defect, P3)
Core
XUL
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: hsivonen, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: helpwanted, platform-parity, Whiteboard: [Win: 0%,0%,0%][Mac: 0%,0%,0%][GTK: 0%,0%,0%])
This is a stage 3 bug for the purpose of the stage scheme of bug 39375. Stages 1 and 2
of this bug are accomplished by using current dialog functionality with stage 1 and 2
implementations of individual widgets. This bug, however, does not depend on stage 3
implementations of particular widgets. This bug covers only alerts--not dialogs in general.
Currently, alert boxes (aka. message boxes) don't follow platform conventions. This could
be fixed by using native alerts. Alert boxes have limited content options and, therefore, it
should be possible to create a cross-platform alert API for creating native alerts.
XP code would call the XP alert API which would, in turn, call the platform alert API.
Benefits:
* Native alerts would follow the system conventions for alerts making it easier for users to
recognize alerts as such.
* Native alerts could most likely be displayed more quickly than alerts rendered with the
browser layout engine.
* Native alerts would be recognized as alerts by the window manager. It is useful when
an alert is created while Mozilla is in the background or with the new alert model of Mac
OS X.
* Utilities that add functionality to alerts would recognize alerts as such.
Properties of an alert box that would need to be supported:
Title (not displayed on all platforms)
Level (severity of the alert)
Primary text
Secondary text (optional)
Checkbox with text (optional)
Default button
Secondary button (optional)
Third button (optional)
Has help (optional)
Title
A string that is used as the title of the alert box on platforms where alerts have titles. The
dialog should be understandable without the title, because alert boxes don't have titles
on all platforms.
Level
Indicates the severity of the alert. There are three possible level: Note/Information,
Caution/Warning and Stop/Critical (Mac OS/Windows). On Mac OS and Windows the
level of the alert is indicated using an icon supplied by the OS. On platforms where alerts
don't have this property, the property is ignored.
Primary text
The essential text of the alert.
Secondary text
Additional narrative that provides more information. On some platforms the secondary
text is displayed using another font.
Checkbox with text
A checkbox with a label. Used for indicating whether the alert should be displayed next
time or whether the decision should be remembered.
Default button
The button activated by pressing Enter or Return.
Secondary button
Another button. Usually used to cancel an action. If the function is similar to "Cancel" or
"No", the shortcut is command-. on Mac OS and esc on Windows.
Third button
A button with a destructive function or a button providing more information. Placed apart
from the default and secondary buttons. (Typically used for "Don't Save" or "More Info...")
When used for "Don't Save", the shortcut is command-d.
Has help
Indicates that help documentation is available for the alert. On Mac OS the help button is
an OS-supplied icon placed to the left of third button (if present). On Windows the help
buttons is a button labeled "?" in the title bar of the alert.
Additional notes:
On Windows alert boxes can include a close button in the title bar. In alerts with multiple
buttons it should be equivalent to the button meaning "Cancel".
On Mac OS the alert boxes should be of the movable type.
Layout guidelines applicable on Mac OS:
http://developer.apple.com/techpubs/mac/HIGOS8Guide/thig-48.html
Reporter | ||
Updated•25 years ago
|
Comment 2•25 years ago
|
||
Expanding to all stages. Alert boxes have a number of platform-specific features
which could be implemented in Stages 1 and 2:
* general layout
* icons (info, caution, error)
* a more general (i.e. more general than OkCancelOverlay.xul) method of ordering
and positioning command buttons, e.g.
- Windows: [Save] [Don't Save] [Cancel] [Help]
- Mac: [?] [Don't Save] [Cancel] [Save]
* hacking in the platform-specific way of drawing attention to the dialog window
(e.g. flashing the taskbar button on Windows, and `Mozilla requires your
attention. Please bring it to the front.' on Mac OS)
* platform-consistent Help button.
Of course, just implementing Stage 3 immediately would be great, but Stages 1 and
2 would be easier and would still be worthwhile.
A slight correction to Henri's comments on the Help button: on Windows, help with
an alert is provided with a `Help' command button in the dialog itself. The `?'
button in the title bar of some Windows dialogs is a dialog-specific equivalent
to Mac OS's Balloon Help; it does not open a separate help window.
Keywords: pp
Summary: Platform-consistent look and feel for alerts → Platform-consistent look and feel for alert boxes
Whiteboard: [Win: 0%][Mac: 0%][GTK: 0%] → [Win: 0%,0%,0%][Mac: 0%,0%,0%][GTK: 0%,0%,0%]
Updated•24 years ago
|
Reporter | ||
Comment 3•24 years ago
|
||
Something like is needed in order to support Sheets on Mac OS X.
Comment 4•23 years ago
|
||
BTW: See bug # 83643 for a diff which adds basic sheet support. Not perfect yet
by any means, but a first step. :)
Tabs are not consistent with Mac OS X. (well, Mozilla's use of tabs, at least)
The tab-per-document metaphor in tabbed browsing undoes most of the benefit of
using Mac OS X sheets for window-modal dialogs (vs app-modal).
It would be nice if tab-specific alerts could be somehow made tab-modal.
bug 123908 suggests a possible approach (background tabs hold on to their alerts
until they're foregrounded, and are drawn differently when an alert is pending).
Can we make this bug depend on bug 123908?
-matt
Updated•4 years ago
|
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•