Last Comment Bug 293439 - preference binding should look on the preferences node when it wants to find the instantApply setting
: preference binding should look on the preferences node when it wants to find ...
Status: RESOLVED DUPLICATE of bug 451025
[good first bug]
:
Product: Toolkit
Classification: Components
Component: Preferences (show other bugs)
: unspecified
: All All
: -- trivial with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Neil Deakin
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-09 01:23 PDT by Daniel Brooks [:db48x]
Modified: 2011-09-28 12:25 PDT (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Daniel Brooks [:db48x] 2005-05-09 01:23:23 PDT
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) 2011-08-15 19:00:32 PDT
Isn't this already the case? http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/preferences.xml#141
Comment 2 Justin Wood (:Callek) 2011-08-15 19:46:27 PDT
(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) 2011-09-28 01:12:49 PDT
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 2011-09-28 12:25:18 PDT
Yes, this was fixed by Daniel himself in bug 451025. http://hg.mozilla.org/mozilla-central/rev/3fe2918df533

*** This bug has been marked as a duplicate of bug 451025 ***

Note You need to log in before you can comment on or make changes to this bug.