Security warning dialogs cannot be made permanent through the checkbox

RESOLVED FIXED

Status

()

Firefox
Preferences
P3
normal
RESOLVED FIXED
14 years ago
12 years ago

People

(Reporter: Gonzalo HIGUERA DÍAZ, Assigned: dbaron)

Tracking

({fixed-aviary1.0, fixed1.7.5})

unspecified
x86
Windows XP
fixed-aviary1.0, fixed1.7.5
Points:
---
Bug Flags:
blocking-aviary1.0 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [patch])

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
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

14 years ago
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.
(Reporter)

Comment 2

14 years ago
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?
no, this would be the right place for that bug.

I need to dig into this.
Assignee: firefox → mconnor
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 4

14 years ago
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. 
Flags: blocking-aviary1.0?
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?
(Reporter)

Comment 6

14 years ago
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.
(Reporter)

Comment 7

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

Woops. Forgot to say that I opened Tools->JavaScript Console and saw no message 
displayed during the whole process.
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?

Updated

14 years ago
Flags: blocking-aviary1.0? → blocking-aviary1.0+
Priority: -- → P3
(Reporter)

Comment 9

14 years ago
(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.

(Assignee)

Comment 10

14 years ago
*** Bug 252360 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

14 years ago
Assignee: mconnor → bryner
(Assignee)

Comment 11

14 years ago
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).
(Assignee)

Comment 12

14 years ago
Created attachment 153845 [details] [diff] [review]
patch (make ConfirmDialog match AlertDialog)
Assignee: bryner → dbaron
Status: NEW → ASSIGNED
(Assignee)

Updated

14 years ago
Attachment #153845 - Flags: superreview?(bryner)
Attachment #153845 - Flags: review?(kaie)
(Assignee)

Updated

14 years ago
Whiteboard: [patch]
Attachment #153845 - Flags: superreview?(bryner) → superreview+
(Assignee)

Updated

14 years ago
Attachment #153845 - Flags: review?(kaie) → review?(jgmyers)

Comment 13

14 years ago
I am currently on vacation and will not be able to review patches until the 
end of this month.
(Assignee)

Updated

14 years ago
Attachment #153845 - Flags: review?(jgmyers) → review?(kaie)
(Assignee)

Updated

14 years ago
Attachment #153845 - Flags: review?(kaie) → review?(bryner)
(Assignee)

Updated

14 years ago
Summary: Security warning dialogues cannot be made permanent through the checkbox → Security warning dialogs cannot be made permanent through the checkbox
(Assignee)

Updated

14 years ago
Attachment #153845 - Flags: approval-aviary?
Attachment #153845 - Flags: review?(bryner) → review+

Comment 14

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

a=asa for aviary checkin
Attachment #153845 - Flags: approval-aviary? → approval-aviary+
(Assignee)

Comment 15

14 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Keywords: fixed-aviary1.0
Resolution: --- → FIXED

Updated

13 years ago
Keywords: fixed1.7.5
sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs,
filter on "beltznerLovesGoats" to get rid of this mass change
QA Contact: mconnor → preferences
You need to log in before you can comment on or make changes to this bug.