(This bug imported from BugSplat, Netscape's internal bugsystem. It was known there as bug #302053 http://scopus.netscape.com/bugsplat/show_bug.cgi?id=302053 Imported into Bugzilla on 02/10/99 23:43) Same as bug 123512 but for unix (other report was for win32)

Spec for one of the two dialogs: int FE_CheckConfirm (MWContext *pContext, char* pDialogTitle, char* pConfirmMessage, char* pCheckMessage, char* pTrueButtonText, char* pFalseButtonText, XP_Bool pFocusedButton, XP_Bool* pChecked); pDialogTitle should be displayed in the title bar of the dialog. pConfirmMessage is the text to be displayed in the body of the dialog. It would be preferable for the FE routine to properly break the string into lines of appropriate lengths; this is only feasable if i18n is willing to help out and make sure the break-iteration is properly implemented. pCheckMessage is the text to be displayed next to the checkbox. If the supplied string is NULL, it is desirable for the checkbox to not be displayed, rendering this a standard dialog. pTrueButtonText is the text to be displayed on the left button. (The button which, when clicked, causes the routine to return true.) pFalseButtonText is the text to be displayed on the right button. pFocusedButton determines whether the left (true) or right (false) button initially has focus. pChecked supplies the initial state of the checkbox. The checked state is written back into that variable before return. The function should return 0 if the right (false) button is clicked, 1 if the left (true) button is clicked, and -1 if the user dismisses the box without selecting (if applicable to platform).

Changing TFV to 5.0 and priority to P1. (Let's make sure we get a bug like this opened on Mac.)

There already is a bug like this filed against the mac. It's 302052

bug in old codebase - looks like this is already implemented in 5.0 XPFE? Marking resolved won't fix in old codebase.

That's news to me. If these api's exist, please tell me where they are? I'm still waiting for them and am temporary doing console writes in the interim. Reoping this until I am convinced that these calls api's really exist.

Okay, I am obviously clueless. I assumed since single sign-on was working (it is right?) that these were implemented. I will open this in Bugzilla. Who should it be assigned to?

Is single-signon a netscape feature? It stays in bugsplat (and not in bugzilla if so). Resummarizing, assigning to don.

What's a Netscape feature? There is no Netscape-only code yet in the tree or is there? Isn't everything in the tree is currently mozilla? Single signon is currently in the tree.

Accepted bug as ASSIGNED. This is not a platform-specific problem. As soon as more of the XPFE is done, we can do something about this ...

Adjusted component, platform, OS, etc.

Re-assigned to davidm@netscape.com.

assign

Set target milestone to M4.

Changed target milestone to M5.

move off to m6 where we should have a "final" dialog arch.

Move off to m7 since the new dialog support will not be done in time

The simple confirm with check is written and checked in. This uber dialog will not be done for a while. Moving off to m9 or so since hopefully the opendialog will finally be callable from c++ by then

Besided FE_CheckConfirm, there is a second routine that is needed as reported in the original bugsplatt report (123512). Namely FE_Select. Somehow the description of that one got lost. It is still needed for single singon. Below is the wording of the original bugsplat report. BTW, both of these routines were indeed added to the codebase in the final days of gromit. ------------------ Steve Morse's cookie management and single signon code requires the use of new dialogs in the 5.0 product. ========================================== I've been asked to add the following statement to the spec below: "Either the dialog box presented by FE_CheckedConfirm will be dynamically sized to accomodate the pConfirmMessage, or the message will appear in a scrolling area. Each FE is free to do whichever of these choices is most appropriate for its environment." Stephen P. Morse wrote: > > Two alternatives were presented for satisfying our current UI needs. > One was to have the FE group write a specialized FE function (one for > each platform of course) for each UI that we need. The other was to > have the FE group generate a synchronous version of MakeHTMLDialog and > then we could write whatever UI's we need using that routine. > > The advantage of the first alternative is that the UI would be prettier > and would come up faster than an HTML dialog. The advantage of the > second is that it would be much less work for the FE group in the long > run because we would never have to ask them for a specialized dialog > again. > > However the feeling was that it would be an architectural hack to > generate a synchronous HTML dialog and would be full of risk. So the > first alternative was agreed upon and I was asked to write up a > detailed spec of the functions that I need. Here goes: > > 1. Cookie Management: Needs a specialized form of FE_Confirm that also > displays a check box. The spec for this function is: > > XP_Bool FE_CheckConfirm ( > MWContext *pContext, > const char* pConfirmMessage, /* main text in box */ > const char* pCheckMessage, /* text alongside checkbox */ > const char* pOKMessage, /* text on the OK button */ > const char* pCancelMessage, /* text on the cancel button */ > XP_Bool* pChecked) /* input: initial state of checkbox, > output: final state of checkbox */ > > /* returned value is TRUE if OK button was pressed, > FALSE otherwise */ > > Note that not only does this add a checkbox to the FE_Confirm dialog, it > also gives the ability to specify the text on the two buttons. That's > not essential (I'm happy with default names) but if the FE group wants > to give us this ability I won't object, as long as it doesn't push out > the availability date. > > 2. Single Signon -- Need the ability to display a scrollable list of > usernames and have the user select one of the entries. The spec for > this function is: > > XP_Bool FE_Select( > MWContext* pContext, > char* pMessage, /* message to appear above the list */ > char** pList, /* array of names to appear in the list */ > int* pCount) /* input: number of names in the list, > output: 0-based index of selected name */ > > /* returned value is TRUE if OK button was pressed, > FALSE otherwise */ ------- Additional Comments From morse 06/05/98 14:21 ------- In the FE_Select dialog, if no item is selected then output value returned in pCount will be -1. In the FE_CheckConfirm dialog, the output value returned in pCheck will be valid in all cases (i.e., even if CANCEL was pressed rather than OK). Although not essential, for consistency the same should be true of pCount returned by FE_Select. ------- Additional Comments From morse 07/20/98 17:31 ------- These bugs have been filed separately agains mac and unix as well. The mac bug is 302052 and the unix one is 302053.

FWIW, the uber dialog as you call it (all the generality with the ability to specify your own names for the buttons) can be dropped completely. I certainly don't need it and I doubt that anybody else does. But I do need the FE_Select dialog as soon as possible. I wish you would reconsider your decision to push that off until M9.

In the past mail news has expressed a desire for an OK/Cancel dialog which can be really customized. As far as doing FE_Select, I am dependant on being able to use openDialog from c++. It is currently scheduled for m8 I believe and if it doesn't go in until the end of m8, I will not be able to write my code until m9.

*** Bug 9028 has been marked as a duplicate of this bug. ***

m10

jevering says to move this to M14.

I have checked in my code ( it is currently if deffed out ) in nsCommonDialogs.cpp for FE_SelectDialog along with my js and xul files.

I have checked in all of davidm's changes to implement this feature. Unfortunately it broke the mac build so I had to back it out for the mac. In particular, I added some ifdefs so that the feature is not on for the mac. The eventual fix probably involves changing a mac project file, and then removing the ifdefs that I added. These ifdefs are as follows: nsWebShellWindow.cpp: around nsWebShellWindow::Select method nsNetSupportDialog.cpp: around nsNetSupportDialog::Select method singsign.cpp: around call to prompter->Select in si_SelectDialog

Davidm's changes that I checked in didn't break the mac build after all -- it was just caught mid-checkin. And by not realizing that, I made things much worse as I tried to ifdef out certain parts. All ifdefs are now removed and this feature is now checked in for all platforms. Marking bug as fixed.

Verified per morse's comments.