52778 - Ok/Cancel overlay needs Help button

Status: VERIFIED FIXED

(SeaMonkey :: Help Documentation, enhancement, P3)

Description

[Matthew T (active 1999-2002)]

The Ok/Cancel overlay allows XPToolkit app authors to create platform-compliant 
dialogs on Windows, X, and Mac OS. However, it is missing two vital features.

1.  Orientation. Dialogs which include commonDialog should be able to specify
    either horizontal orientation (the default) or vertical orientation.
    Horizontal orientation looks like this:

    |       ( Other1 ) ( Other2 )             ( Cancel ) ((  Ok  )) | [X, Mac OS]
    +---------------------------------------------------------------+

    |                   [[  Ok  ]] [ Cancel ] [ Other1 ] [ Other2 ] | [Windows]
    +---------------------------------------------------------------+

    Vertical orientation looks like this on all platforms:

    ----------------------------------------------------------------+
    ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
    ----------------------------------------------------------------+
                                                         ((  Ok  )) |
                                                         ( Cancel ) |
                                                                    |
                                                         ( Other1 ) |
                                                         ( Other2 ) |
                                                         (Other3..) |

    Vertical orientation is important to provide consistent placement of buttons
    (and therefore faster clicking) in dialogs which may vary in height from
    instance to instance. An example of this is the cookie confirmation dialog
    (bug 23508).

2.  The Ok/Cancel overlay needs to take a flag indicating whether a Help button
    is present. A window with a Help button looks like this:

    |       [?] ( Other1 ) ( Other2 )         ( Cancel ) ((  Ok  )) | [X, Mac OS]
    +---------------------------------------------------------------+
    <http://developer.apple.com/techpubs/mac/HIGOS8Guide/graphics/HIG_CG-070.gif>
    (Note that the Help button has a rectangular border on Mac OS, whereas the
    other buttons are rounded. On X, all the buttons would be rectangular.)

    |          [[  Ok  ]] [ Cancel ] [ Other1 ] [ Other2 ] [ Help ] | [Windows]
    +---------------------------------------------------------------+
    <http://msdn.microsoft.com/library/books/winguide/images\13_07.GIF>

Comment 1

[Ben Bucksch (:BenB)]

> 1.  Orientation.

What makes you think that? I saw code for that, but I don't know the state or
how it is enabled.

> |       [?] ( Other1 ) ( Other2 )         ( Cancel ) ((  Ok  )) | [X, Mac OS]

No, GNOME looks like Windows. See example screenshot
<http://bugzilla.mozilla.org/showattachment.cgi?attach_id=14775>.

Comment 2

[Ben Bucksch (:BenB)]

> No, GNOME looks like Windows.

(Of course, it doesn't, I meant just this layout.)

Wrong, as you can see from the screenshot (OK - Apply - Close - Help).
Unix/GTK/GNOME doesn't have strict UI guidelines yet anyway, but common seems to
be the following layout: OK - [Apply -] Custom 1 - Custom 2 - Close - Help.

Comment 3

[Peter Trudelle]

One issue per bug report, please.  Two features, two reports. Good stuff, but of
course no time now. ->future

Comment 4

[Ben Bucksch (:BenB)]

> One issue per bug report, please.

Narrowing summary to Help button.

Comment 5

[Peter Trudelle]

mass-acceptance

Comment 6

[Simon Fraser [no longer active]]

This is required for Help, and for the Security dialogs (see bug 76248). It needs 
to be dragged back from Future.

Comment 7

[Peter Trudelle]

Daniel sez Ben touches this most (and we have not- ever), attempting
reassignment.

Comment 8

[David P. Drinan]

Is this bug being actively worked on? If so, any idea of when it will be fixed. 
If this is not going to be fixed, please let me know so I can consider 
workarounds for this.

Comment 9

[Blake Ross]

--> Help

Comment 10

[Ian Oeschger (gone)]

Attachment: example of what's needed in the dialog overlays (win only)

Comment 11

[Ian Oeschger (gone)]

I don't think this is my bug to accept, so leaving as NEW. Ben, Blake,
Simon...anyone? The attached patch is a sample of what we need to get a help
button into the overlay (since, I think, there will be no <dialog /> soon and we
will continue to use the overlays for the time being).

Note the import of the help script, where openHelp() is not yet but will be
defined as a window-mediator-based way to open the help window, with
context-sensitivity if you want.

help wanted!

Comment 12

[Simon Fraser [no longer active]]

Comments:
+<script type="application/x-javascript" src="chrome://chrome/content/help.js"/>

I don't think we want to load a new JS file for every dialog. help.js should be 
loaded by dialogs that want help.

+    <button class="exit-dialog" id="help" label="&helpButton.label;" oncommand=
"openHelp();"/>

This should be an 'onHelp()' function, I think, that will be implemented in the 
JS of dialogs that use the 'okCancelHelpButtons' box.

Comment 13

[Ian Oeschger (gone)]

Checked in fix for this yesterday. dialog overlays now have two different sets 
of buttons <box id="okCancelHelpButtons" /> and <box 
id="okCancelHelpButtonsRight" />.

Dialogs that use these button sets must implement their own doHelpButton() 
function. See 46226 for preferences dialog implementation of this.

Comment 14

[Brant Gurganus]

v