293439 - preference binding should look on the preferences node when it wants to find the instantApply setting

Status: RESOLVED DUPLICATE of bug 451025

(Toolkit :: Preferences, defect)

Description

[Daniel Brooks [:db48x]]

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.

Comment 1

[Joe Drew (not getting mail)]

Isn't this already the case? http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/preferences.xml#141

Comment 2

[Justin Wood (:Callek)]

(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>)

Comment 3

[Felix Fung (:felix)]

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.

Comment 4

[Nickolay_Ponomarev]

Yes, this was fixed by Daniel himself in bug 451025. http://hg.mozilla.org/mozilla-central/rev/3fe2918df533