The default bug view has changed. See this FAQ.

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

RESOLVED DUPLICATE of bug 451025

Status

()

Toolkit
Preferences
--
trivial
RESOLVED DUPLICATE of bug 451025
12 years ago
6 years ago

People

(Reporter: db48x, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [good first bug])

(Reporter)

Description

12 years ago
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.
QA Contact: nobody → preferences
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>)
Assignee: db48x → nobody
Whiteboard: [good first bug]

Comment 3

6 years ago
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

6 years ago
Yes, this was fixed by Daniel himself in bug 451025. http://hg.mozilla.org/mozilla-central/rev/3fe2918df533
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 451025
You need to log in before you can comment on or make changes to this bug.