245655 - Security warning dialogs cannot be made permanent through the checkbox

Status: RESOLVED FIXED

(Firefox :: Settings UI, defect, P3)

Description

[Gonzalo HIGUERA DÍAZ]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040604 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040604 Firefox/0.8.0+

When doing an insecure submit for the first time (for example when entering a
search term in http://www.google.com/) a warning dialogue appears with a
checkbox allowing you to see such warnings in the future disabled. When a
submission occurs and the checkbox is left blank, further searches will
naturally not prompt further warnings. On the other hand, when the box is
checked the dialog will appear again during a second submission.

The problem lies in that when the dialog appears for the second time, the
checkbox is blank again, forcing the security conscious user to have to check it
after each submission, and eventually making him desist.

A workaround is to enter as a URL "about:config" and make
security.warn_submit_insecure.show_once false (and if necessary make
security.warn_submit_insecure true again).

This problem is probably true for other options of the security.warn_* kind.

Reproducible: Always
Steps to Reproduce:
1. Fill in an insecure form (such as the one in http://www.google.com/) and try
to submit it.
2. In the warning dialog that appears, check the box allowing for futher similar
warnings to appear.
3. Repeat the first step.

Actual Results:  
The checkbox in the warning dialog is again unchecked.

Expected Results:  
The checkbox should have appeared as selected.

Comment 1

[Jesse Ruderman]

Bryner fixed this in bug 172091, but you are using a new trunk build, so either
this is a regression or Bryner's fix didn't work completely.

Comment 2

[Gonzalo HIGUERA DÍAZ]

I have confirmed the bug under Windows using the following builds with fresh
profiles:

-0.9rc
-2004-06-11-09-0.9
-2004-06-11-14-trunk

As a side note, comment #71 of the original bug report (bug 172091) suggests
that others have seen the problem after the fix. Should it then be reopened and
this one marked as a duplicate?

Comment 3

[Mike Connor [:mconnor]]

no, this would be the right place for that bug.

I need to dig into this.

Comment 4

[Asa Dotzler [:asa]]

This really seems like something we should fix for 1.0.  Not remembering the
checked state in this dialog sucks. (we may have other bugs on this). I think
what happened is that we (blake?) incorrectly overrided the default state to be
not checked to avoid pestering users who were too newbie to know they can get
rid of that dialog by unchecking the box. 

Comment 5

[Mike Connor [:mconnor]]

As a note, I can't replicate this any more on aviary, and the code looks fine to
me.  Can anyone actually reproduce this, and are their JS errors in the console?

Comment 6

[Gonzalo HIGUERA DÍAZ]

I have repeated the tests that drove me to write the bug report and I find that 
it still does not work for me. Please test and report in case it is something 
with my Windows XP Professional configuration. Step by step:

Using http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2004-07-16-12-
0.9/Firefox-win32.zip (is that from the aviary branch?) I unzip the files and 
create a shortcut to run with the -p option. I then create profile "asdf" and 
start Firefox. I say "No" to making Firefox the default (blasphemy! ;-)) 
unticking the box. I fill in my proxy settings through the Options menu. I go 
to http://www.google.com/ and enter a seach term. I press "Google Search". A 
security warning appears with the box unchecked. I check it and 
press "Continue". Novelty: the warning appears *again* ... unchecked. This 
second time, checking it and pressing "Continue" performs the search. However, 
doing another search leads me to the original situation.

Comment 7

[Gonzalo HIGUERA DÍAZ]

(In reply to comment #6)
> [...]

Woops. Forgot to say that I opened Tools->JavaScript Console and saw no message 
displayed during the whole process.

Comment 8

[Mike Connor [:mconnor]]

if you go to about:config and filter on security.warn, are any of the prefs
changing?  Are you testing with a totally clean install (to a new directory) etc?

Comment 9

[Gonzalo HIGUERA DÍAZ]

(In reply to comment #8)
> if you go to about:config and filter on security.warn, are any of the prefs
> changing?

In the first step (ticking the checkbox and pressing "Continue" in order to 
submit the first search) nothing changes (all values are "true", non-bold). 
When I submit for the second time--and again the box is unckecked--
pressing "Continue" changes security.warn_submit_insecure to "false" (bold).

As I stated above, making security.warn_submit_insecure.show_once "false" 
manually creates the expected behaviour (i.e. the warning dialogue showing with 
the box checked until it is unchecked). There are no more 
security.warn_submit_insecure options apart from those two.


> Are you testing with a totally clean install (to a new directory) etc?

Sorry for lacking precision. When I said "I unzip the files" I implied that it 
was to a new arbitrary directory.

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

bug 172091 was never really fixed because of a small mistake in the patch --
ConfirmDialog never sets the show_once pref to false (it sets it to true instead).

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch (make ConfirmDialog match AlertDialog)

Comment 13

[John G. Myers]

I am currently on vacation and will not be able to review patches until the 
end of this month.

Comment 14

[Asa Dotzler [:asa]]

Comment on attachment 153845 [details] [diff] [review]
patch (make ConfirmDialog match AlertDialog)

a=asa for aviary checkin

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Fix checked in to trunk, 2004-08-27 15:10 -0700.
Fix checked in to AVIARY_1_0_20040515_BRANCH, 2004-08-27 15:10 -0700.

Comment 16

[Mike Connor [:mconnor]]

sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs,
filter on "beltznerLovesGoats" to get rid of this mass change