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.
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.
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
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.
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?
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.
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?
(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.
*** Bug 252360 has been marked as a duplicate of this bug. ***
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).
Created attachment 153845 [details] [diff] [review] patch (make ConfirmDialog match AlertDialog)
Assignee: bryner → dbaron
Status: NEW → ASSIGNED
Attachment #153845 - Flags: superreview?(bryner) → superreview+
Attachment #153845 - Flags: review?(kaie) → review?(jgmyers)
I am currently on vacation and will not be able to review patches until the end of this month.
Attachment #153845 - Flags: review?(jgmyers) → review?(kaie)
Attachment #153845 - Flags: review?(kaie) → review?(bryner)
Summary: Security warning dialogues cannot be made permanent through the checkbox → Security warning dialogs cannot be made permanent through the checkbox
Attachment #153845 - Flags: approval-aviary?
Attachment #153845 - Flags: review?(bryner) → review+
Comment on attachment 153845 [details] [diff] [review] patch (make ConfirmDialog match AlertDialog) a=asa for aviary checkin
Attachment #153845 - Flags: approval-aviary? → approval-aviary+
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
Resolution: --- → FIXED
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.