Closed
Bug 284143
Opened 19 years ago
Closed 19 years ago
Javascript option "But disable common annoyances" sets options on disable, not on enable
Categories
(Firefox :: Settings UI, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: g.teunis, Assigned: bugs)
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050228 Firefox/1.0+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050228 Firefox/1.0+ When disabling Javascipt option "But disable common annoyances" the "dom.disable_window_open_feature.status" and "dom.disable_window_status_change" are set to TRUE. When enabling "But disable common annoyances" it does NOT set the 2 options to false again. A error in disabeling/enabling "But disable common annoyances"? Reproducible: Always Steps to Reproduce: 1. Open about:config 2. Set "dom.disable_window_open_feature.status" and "dom.disable_window_status_change" to FALSE 3. Go to options, content and enable "But disable common annoyances" (the step 2 options do not change). 4. Disable "But disable common annoyances", the step 2 options are set to TRUE. 5. Enable "But disable common annoyances" again, step 2 options are still TRUE. The 2 options are clearly set to TRUE when the "But disable common annoyances" is disabled. The options are not set to FALSE when the "But disable common annoyances" is set to true.
Comment 1•19 years ago
|
||
WFM I see both prefs TRUE when disable annoyances is enabled and FALSE when disabled and they happily change between as I would expect. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050228 Firefox/1.0+
Reporter | ||
Comment 2•19 years ago
|
||
I figured it out: It is only triggered when the about:config is opened during "But disable common annoyances" change. I figure this might be another bug resulting in options not correctly changed when about:config is opened.
Comment 3•19 years ago
|
||
I did my testing with about:config open.
Reporter | ||
Comment 4•19 years ago
|
||
Call me crazy: it can't reproduce it anymore. I did really test it over and over (all possible testcases). Weird. I resolve it to INVALID myself.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 5•19 years ago
|
||
Sorry for the bugspam, should be WORKSFORME.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Reporter | ||
Updated•19 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → WORKSFORME
Comment 6•19 years ago
|
||
I am concerned that there is something going on here. I experienced a similar situation, testing some preferences from the options pane and finding them not working at all, then all of a sudden they started working again. Hopefully there isn't some intermittent problem here.
Comment 7•18 years ago
|
||
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.
Description
•