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>

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

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

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

> One issue per bug report, please. Narrowing summary to Help button.

mass-acceptance

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

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

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.

--> Help

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!

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.

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.

v