Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050802 Firefox/1.0+ ID:2005080213 repro: 1.Go to tools -> Options -> Update 2.Check Automatically check for updates to: Deerpark 3.Notice the part "When updates to deerpark are found..." remains grayed out. 4.Press OK workaround: Close options and reopen options Now the lower options can be selected

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050802 Firefox/1.0+ ID:2005080214 For me, that lower part is initially enabled (it shouldn't be), and checking and unchecking the Deer Park checkbox will make it behave normally. This was observed when opening the prefs. dialog for the first time in a new profile. After the initial opening of the prefs. window it seems to work fine.

Ben should probably have this on his radar.

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

From the testing I've done, the onchange events for app.update.enable are NOT being fired when the checkbox value is changed.

From all the testing I've done, the onchange events for <preference> were NOT working. I then went over to privacy.xul to test the same thing, and found that the onchange on the network.cookie.behavior preference was not doing anything either (unless I'm screwing up horribly here). So then I just decided to put onsynctopreference in the <radiogroup> for the update panel. Seems to do the job properly, but would love to here from ben if this is the right fix or not (and if not, how to get onchange working).

This looks like something we do need to get fixed. Ben can you look into thist?

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

Try some things for me: 1. open two browser windows 2. in one of them, open the options dialog 3. in the other, open about:config 4. bring up this panel 5. in the about:config window toggle all of the prefs by hand Does the UI update automagically at the same time? If so this works.

if i check updates to Deer Park in the options window, then switch windows to about:config, then set app.update.enabled to false, i find updates to deer park unchecked so, it works

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20050830 Firefox/1.6a1 ID:2005083019 Yes, this pref. is updated automatically when you toggle the pref. in about:config.

then WFM.

Comment on attachment 191613 [details] [diff] [review] possible fix r=ben@mozilla.org

time is short for beta so if this is gonna make the branch, it needs to land ASAP.

Updated patch to (hopefully) apply to the tree now.

THIS should do it. Sorry for bugspam.

I just wanted to make it clear that I followed Ben's steps to prove that the onchange events were getting fired /without/ Aaron's patch applied. Also, the steps to reproduce this are a bit bitrotted because we now enable this checkbox by default. I couldn't reproduce this on either XP or Linux with today's trunk build.

Comment on attachment 194877 [details] [diff] [review] crap happens Well, if the onchange events are being fired, then this patch is completely useless. Anyways, testcase in comment 0 is not even applicable anymore, as nothing ever get grayed out now, period. If we can get a new testcase, an alternative fix can be made, but right now as it stands, the current patch will not fix anything, so let's not check this in, please.

Currently, checking or clearing the "Firefox" checkbox does not enable/disable the lower part ("When updates are found"). The "When updates are found" section should be disabled when the "Firefox" checkbox is cleared, and enabled when that checkbox is checked.

(In reply to comment #18) > Currently, checking or clearing the "Firefox" checkbox does not enable/disable > the lower part ("When updates are found"). It also seems (it might be another bug though) that even if the "check for firefox updates" checkbox is unchecked, DPA still searches for updates and installs them silently or asks, as configered below. That's what I've been experiencing for the last week.

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

Scott: Note theunderbird needs the same fix. Check in on trunk: mozilla/browser/components/preferences/advanced.js 1.20 mozilla/browser/components/preferences/advanced.xul 1.22

checked in on trunk: mozilla/mail/components/preferences/advanced.js 1.17 mozilla/mail/components/preferences/advanced.xul 1.16

1.8 BRANCH: mozilla/browser/components/preferences/advanced.js 1.15.2.4 mozilla/browser/components/preferences/advanced.xul 1.17.2.4 mozilla/mail/components/preferences/advanced.js 1.13.2.3 mozilla/mail/components/preferences/advanced.xul 1.13.2.2

Does anyone know of an open bug for "Warn me if this will disable extensions or themes" not greying out when its parent radio button is deselected? I've searched for "options greyed advanced", "options grey update", "options grey advanced", and a lot of other combinations, but I still can't find one. Thanks.

I am not very happy with this patch. It doesn't work like it should at all: 1. If "Firefox" checkbox is disabled when opening Options - Advanced, then the radio-buttons below are disabled as they should. However, when you check "Firefox", the radio-buttons are still disabled. They should be enabled upon checking "Firefox". Now, they are only enabled after clicking "OK" to close Options, and then reopening Options. 2. The "Ask me what to do" radio-button is not selected after you open Options for the second time. In fact, no radio-button at all is selected in that case. If you choose "Automatically download..." however, this setting is selected (remembered) after opening Opions again. 3. (Same as 1.) If you choose "Automatically download..." after you chose "Ask me what to do" first (and closing/reopening Options), the checkbox for "Warn me..." is not automatically enabled. That happens only after closing and reopening Options. Requesting reopening.

(In reply to comment #27) > I am not very happy with this patch. 2 and 3 are bug 309015 (bug 309016).

That's an issue with instantApply turned off which which will be fixed by bug 308966.

(I referred to point 1 in comment 27).