10944 - [RFE]Add Option to turn-off ("remember") database pwd in the database pwd dialogue

Status: VERIFIED DUPLICATE of bug 13022

(Toolkit :: Form Manager, enhancement, P3)

Description

[kevinyen]

Steve, Vera, and I just met on this:

Exact wording is forthcoming (first week in August), but idea is that:

To the password protection dialogue, add something like:
[ ] Check here to remember this password...
 - OR -
[ ] Check here to turn off password protection...

The idea is to allow people to turn off the password key protection at the
moment the user may want to.

thx,
kevin

Comment 1

[kevinyen]

Steve,
From last week's (?) discussion with DP, you, and me, the big blocker on going
through with this was whether or not a dialog-widget existed that had both (1)
a field input, and (2) checkbox input.

I believe we do have such a widget.  It's currently implemented for opening
files.  To see in Seamonkey, do:  File... Open File or Location...

Let me know if this will not suffice, and/or if there's any other info you need
to make a decn.

Remember, the exact text we can craft/update later.

thx,
kevin

Comment 2

[davidm]

The nsICommonDialog can be customized to give a dialog with an editfield and a
checkbox. You can use ConfirmCheck as a template of what to do and just add in
the needed editfield. I am not keen on adding more convience methods ( alert,
confirm, ... ) to nsICommonDialogs unless you can convince me that more than one
client wants this feature.

Comment 3

[Stephen P. Morse]

Kevin, the "open file or location" dialog is close  But what do you propose we
do with the "chose" button in that dialog?

-- Steve

Comment 4

[kevinyen]

David -- How can Steve make the "Choose" button disappear?  Or is it feasible to
have a dialog-type that does not have the "choose" button?

thx,
kevin

Comment 5

[Stephen P. Morse]

Kevin, it's feasible to create any dialog type that you want.  David just didn't
want an unnecessary proliferation of them.

Comment 6

[kevinyen]

Understandable.  Since "unnecessary" is in the eye of the beholder, then let me
re-phrase.

David -- Can we have this dialog, please?  We can discuss it together, but such
a dialog would allow us to make a notable improvement in the UE of a high
profile feature.  It may have other applications, too  Let's talk about the
details if you have questions or just want to do so before you decide.  Just let
me know.

thx,
kevin

Comment 7

[davidm]

You don't want to be using the open file or location dialog if I understand what

you want ( a password dialog with a check box). Using the nsICommonDialogs

something along the lines of ( Not having been tested it at all )

	static nsresult PromptPasswordCheck(nsIDOMWindow *inParent, const PRUnichar *

inMsg,const PRUnichar *inCheckMsg, PRBool *outCheckValue,  PRUnichar **

outPassword, PRBool *_retval)

{

	nsresult rv;

	nsIDialogParamBlock* block = NULL;

	rv = nsComponentManager::CreateInstance( kDialogParamBlockCID,

                                                      0,



nsIDialogParamBlock::GetIID(),

                                                      (void**)&block );



	if ( NS_FAILED( rv ) )

		return rv;

	// Stuff in Parameters

	block->SetInt( eNumberButtons,2 );

	block->SetString( eMsg, inMsg );



	nsString url( "chrome://global/skin/question-icon.gif" );

	block->SetString( eIconURL, url.GetUnicode());

	block->SetInt( eNumberEditfields, 1 );

	block->SetInt( eEditField1Password, 1 );

	block->SetString( eCheckboxMsg, inCheckMsg );

	block->SetInt(eCheckboxState, *outCheckValue );



	NS_WITH_SERVICE(nsICommonDialogs, dialog, kCommonDialogsCID, &rv);

 	if ( NS_SUCCEEDED( rv ) )

    {

       rv = dialog->DoDialog( inParent, block, "chrome://global/content/

commonDialog.xul" );

	   block->GetString( eEditfield2Value, outPassword );

	   PRInt32 tempInt = 0;

	   block->GetInt( eButtonPressed, &tempInt );

	   *_retval = tempInt ? PR_FALSE : PR_TRUE;

	   block->GetInt(eCheckboxState, & tempInt  );

	   *outCheckValue = PRBool( tempInt );

	}

	NS_IF_RELEASE( block );

	return rv;

}



should do the trick. When things like default buttons and keyboard navigation

show up they should just work in your dialog. If the dialog is only used once I

don't want to put it in my XPCOM interface since there are potentially a huge

number of dialogs ( any combination of: 1-2 ( soon to be 3) buttons, 0-2

editfields, 0-1 checkboxes, 3 or 4 different icons,different message titles ) so

I don't want to bloat everyone with code that is only used by one module.

Comment 8

[davidm]

Pretty cool how it decided to double space my reply. Must have been that mid-air
collision;)

Comment 9

[kevinyen]

Thanks, David.

Steve -- can we give this a spin?

thx,
kevin

Comment 10

[Stephen P. Morse]

There was a meeting held yesterday to discuss wallet UE issues.  Bug 13022 was
opened to track all UE changes agreed to.  This issue was brought up at that
meeting but no resolution was reached.  It was left in German's hands to come up
with a resolution.  If he decides we should make this change, then that will be
added as another item in bug 13022.  This report is being closed a a duplicate
of that report.


*** This bug has been marked as a duplicate of 13022 ***

Comment 11

[Asa Dotzler [:asa]]

ok, verified.  wallet ue changes found at 13022

Comment 12

[Brant Gurganus]

[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.