The goal here is to not have promptservice consumers depending on intl like they do now. nsIPrompService2 will have a way to pass it which stringbundle and dialog id to use for localizable stuff ("text", "dialogtitle", "buttonNtitle", checkbox labels, etc). The caller will pass those. The dialog id is used to grab both the dialog title and that dialog's text(s) from the bundle. This will necessitate establishing a naming convention for the strinbundle entries. Note: "advice" for dialogs can be done this way too. Example: Say I call confirm(). I pass "foo" for the stringbundle and "bar" for dialog id. The service impl looks up the resource://foo stringbundle (real URI may vary and all) and looks up the following strings in it: bar.title (which may not be used by some promptservice impls) bar.text bar.advice (if it's there; this may not be relevant to confirm()) and displays those in the "dialog" (or its titlebar) it puts up. Checkboxes could be handled as follows, maybe: The caller will pass in a "prefstring" to store the checkbox value in. The promptservice will create the actual check message out of thin air and store the checkbox state in the pref. There may need to be a special syntax for the "prefstring" that says "this is a path in the Windows Registry" or "Mac system something" or "gconf". Using this means there is no need to pass back out the checkbox state. The promptservice itself could handle checking these prefs to see whether the user wants to actually see the dialog and which response to give if not. The select() method has two callers -- singsing and mailnews mail import from Nav4x profiles (to select a profile). The latter should use profile manager ui or some such for the profile selection, and the former just needs to be beat around the head (dwitte? mvl?). Then we can eliminate this function here and on nsIPrompt. We also want to replace alert() with error() and note() (which will need to use different icons on MacOS, eg). We probably want to rename prompt() to getString(). We can have a small embedding component implementing nsIPromptService2 that just handles the localization and calls through to the PromptService contract, which makes all this transparent to those embeddors who don't feel like implementing nsIPromptService2. Our own promptservice impl can implement nsIPromptService2, to fix things like the alert() issue (using error() and note() instead), though. See bug 95649 and bug 99615 for previous discussion; that's where the issues we're trying to resolve were mentioned. Note that this bug is somewhat independent of freezing nsIPromptService, since it will provide a compatibility layer with that interface.

hmm... what necko needs is an API that takes a nsIAuthPrompt (or maybe a nsIChannel), and then puts up an auth prompt corresponding to one of the following elements from necko.properties: EnterUserPasswordForRealm=Enter username and password for %1$S at %2$S EnterUserPasswordForProxy=Enter username and password for proxy at %1$S EnterUserPasswordFor=Enter username and password for %1$S EnterPasswordFor=Enter password for %1$S on %2$S perhaps nsIPromptService2 is more general in scope. either way, i think i would like to do something simple like this for protocol handlers. however, there's also the issue of trying to make these auth prompts more descriptive (see numerous bugs on file). for example, our auth prompts should tell the user if their password is going to be sent over the wire in the clear, etc. we should also highlight the hostname better, etc. so, perhaps these existing string bundle keys are not really representative of the kinds of auth prompts that we want to be putting up in the future. at any rate, my point is that i think the protocol handlers probably want something more specialized to protocol handlers (whatever that means) ;-)

Marking a bunch of bugs in the "Embedding: APIs" component INCOMPLETE in preparation to archive that component. If I have done this incorrectly, please reopen the bugs and move them to a more correct component as we don't have "embedding" APIs any more.