228207 - Implement nsIPromptService2

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Embedding: APIs, defect)

Description

[Boris Zbarsky [:bzbarsky]]

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.

Comment 1

[Darin Fisher]

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) ;-)

Comment 2

[Benjamin Smedberg]

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.