The problem is that the preference binding assumes it's being used inside a prefwindow when it tries to find the value of the instant apply pref. This means that you have to specify explicitly that instantApply is on each pref you have in the document. The solution is to make the preferences binding look up that setting instead of the prefwindow, and to make the preference binding look for the setting in the new location. I'll attach a patch later.
Isn't this already the case? http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/preferences.xml#141
(In reply to Daniel Brooks from comment #0) > The solution is to make the preferences binding look up that setting instead > of > the prefwindow, and to make the preference binding look for the setting in > the > new location. > > I'll attach a patch later. Apparantly ... 6 years later ... that this later never came or was forgotton :( (In reply to Joe Drew (:JOEDREW!) from comment #1) > Isn't this already the case? > http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/ > preferences.xml#141 No. that does: return this.getAttribute("instantApply") == "true" || this.preferences.instantApply; Which as said, checks the <preference ... instantApply="true" /> failing it being there it explicitly checks for the _prefwindow_ instantApply setting (which checks the prefs) via: <property name="preferences" onget="return this.parentNode"/> Instead it should do a check on if the parentNode is the node we expect, otherwise do basically the same thing as there: this.instantApply = psvc.getBoolPref("browser.preferences.instantApply"); And store it locally in the <preference> (to allow this binding to be used from outside of a <prefwindow>)
I think comment 1 is correct. It seems like this bug is already resolved. <property name="preferences" onget="return this.parentNode"/> is a property on <preference> whose parentNode is defined to be <preferences> ... and so this.preferences.instantApply ends up calling ... <property name="instantApply" readonly="true"> <getter> <![CDATA[ var doc = document.documentElement; return this.type == "child" ? doc.instantApply : doc.instantApply || this.rootBranch.getBoolPref("browser.preferentApply"); ]]> </getter> </property> ... where this.rootBranch = nsIPrefBranch. There doesn't seem to be any assumptions about any prefWindow anymore.
Yes, this was fixed by Daniel himself in bug 451025. http://hg.mozilla.org/mozilla-central/rev/3fe2918df533