ConfirmCheck not giving correct value if CANCEL is pressed

VERIFIED FIXED in M7

Status

P3
normal
VERIFIED FIXED
20 years ago
14 years ago

People

(Reporter: morse, Assigned: davidm)

Tracking

Trunk
x86
Windows NT

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

20 years ago
The ConfirmCheck dialog in nsINetSupportDialogService is supposed to return the
value of the checkbox when either the OK or CANCEL button is pressed.  It works
fine when the OK button is pressed.  But it gives garbage when the CANCEL button
is pressed.

This is important when you consider how this dialog is being used.  In cookie
management, for example, we use it to put up a dialog "Do you want to accept
this cookie" along with a checkbox of "Remember this decision."  If the checkbox
is checked, we want to remember whether the user accepted (OK)as well as
rejected (CANCEL) the cookie.

A more striking example is in form submission.  Here the dialog says "Do you
want to save the values on this form" and the checkbox says "Never save this
form."  In this case the checkbox is actually ignored if the user presses OK.
The checkbox has meaning only if the user presses CANCEL (meaning don't save
this form this time) and then checks the box telling us to never even ask him
about this form in the future.
(Assignee)

Updated

20 years ago
Status: NEW → ASSIGNED
Target Milestone: M7
(Assignee)

Comment 1

20 years ago
accept m7.
you can just copy and paste
	if ( mCheckValue )
		GetCheckboxValue( mWebShell, "checkbox", *mCheckValue );
into the onCancel handler if you can't wait for me to check in the fix. BTW do
you need the ability to set the checkbox value? Currently I think it always
defaults to unchecked.
(Reporter)

Comment 2

20 years ago
Yes, I do need the ability to set the checkbox to an initial value.  Thanks for
reminding me.
(Reporter)

Updated

20 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → FIXED
(Reporter)

Comment 3

20 years ago
OK, I just fixed this.  Added code to the OnCancel handler in
nsNetSupportDialog.cpp per davidm's suggestion.

Updated

20 years ago
Status: RESOLVED → VERIFIED

Comment 4

20 years ago
Assuming fixed (can't verify). morse, if this isn't fixed for any reason, please
re-open this bug. thanks!
(Reporter)

Comment 5

20 years ago
Sure you can verify it but I guess I didn't give a description of the symptoms,
only of the internal details.  Here's what the symptoms were.

1. Get to a sample form and hit submit
2. A pop-up box appears saying something like
      "Do you want to save these values"
   along with a checkbox of
      "Never save values from this site"
3. Check the box and press cancel
4. Submit the form a second time.  The pop-up appeared again

The pop-up in step 4 should not occur because in step 3 you checked off that you
didn't want any saving from this url.  But, because you hit the cancel button
and this bug was causing the checkbox to be returned incorrectly if you hit the
cancel button, the popup did reoccur in step 4.

To fully test this out, see that the other combinations are working correctly --
i.e., CANCEL and CHECKED, CANCEL and NOT CHECKED, OK and NOT CHECKED.  Note that
OK and CHECKED makes no sense so don't report it's incorrect behavior as a bug.

Also make sure you either destroy your profile between tests or you use
different sample forms for each test.  Whenever bug 5410 or 6480 are fixed,
you'll be able to use the single-signon viewer to unremember the sites whose
forms you didn't want saved but for now you need to destroy your profile to
unremember this (or at least delete the file url.<something> (I forget the
suffix) in your profile directory.

Updated

20 years ago
Status: VERIFIED → REOPENED

Updated

20 years ago
Status: REOPENED → RESOLVED
Last Resolved: 20 years ago20 years ago

Comment 6

20 years ago
Will verify fixed next Monday.

Updated

20 years ago
Status: RESOLVED → VERIFIED

Comment 7

20 years ago
Thanks for the detailed steps to reproduce. Using the 1999061409 build, NT 4,
and the stupid URL above, I was not able to reproduce this bug. Marking verified
fixed.

Comment 8

19 years ago
Changing component to XP Apps. (HTML Dialogs is going away.)
Component: HTML Dialogs → XPApps
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.