Disable chrome://options UI elements if the corresponding preference is not user-modifiable.

chrome/browser/resources/options/pref_ui.js

Index: chrome/browser/resources/options/pref_ui.js
diff --git a/chrome/browser/resources/options/pref_ui.js b/chrome/browser/resources/options/pref_ui.js
index 3b85d137cd5072b8244daf125c64d44c7273a6eb..b7b471105ecc64ce4a51889e2bfffe6e21bf94ce 100644
--- a/chrome/browser/resources/options/pref_ui.js
+++ b/chrome/browser/resources/options/pref_ui.js
@@ -13,18 +13,34 @@ cr.define('options', function() {
    * @param {!Event} event The pref change event.
    */
   function updateElementState_(el, event) {
-    el.managed = event.value && event.value['managed'] != undefined ?
-        event.value['managed'] : false;
-
-    // Managed UI elements can only be disabled as a result of being
-    // managed. They cannot be enabled as a result of a pref being
-    // unmanaged.
-    if (el.managed)
-      el.disabled = true;
-
-    // Disable UI elements if backend says so.
-    if (!el.disabled && event.value && event.value['disabled'])
-      el.disabled = true;
+    el.managed = false;
+
+    if (!event.value)
+      return;
+
+    el.managed = event.value['managed'];
+
+    // If the value is controlled by an extension, set an explanatory title
+    // attribute on the nearest containing <label> element.
+    var label = findAncestor(el, function(node) {
+      return (node instanceof HTMLLabelElement);
+    });
+    if (label) {
+      label.title = event.value['extensionControlled'] ?
+          templateData.extensionManagedPrefsTitle :
+          null;

[Evan Stade, 2011/07/07 20:06:45]

this will overwrite whatever other title the label may have had, but I guess we
don't use title elsewhere

[Bernhard Bauer, 2011/07/07 20:45:14]

Per the UI leads, we're going to add an infobar like the one for policy-managed
settings in this case as well, so I guess the title won't be necessary any more.
OTOH, that's going to be a somewhat bigger change, so I'd like to get the
disabling in first.

+    }
+
+    // Disable UI elements if the backend says so.
+    // |reenable| is a flag that tells us if the element is disabled because the
+    // preference is not modifiable by the user. If the element is disabled but
+    // the flag is not set, it means that the element has been disabled
+    // somewhere else, so we don't do anything.
+    if (el.disabled && !el.reenable)
+      return;
+
+    el.disabled = event.value['disabled'];

[Evan Stade, 2011/07/07 20:06:45]

this still doesn't seem very foolproof. reenable could be stale (the preference
*was* disabled somewhere else, but no longer is). Actually if that happens then
probably |disabled| has been overwritten elsewhere. I don't see an easy way out
of this... wdyt?

[Bernhard Bauer, 2011/07/07 20:45:14]

I know :-/ This seemed like the easiest way without having to change every other
place that disables UI elements. 
That would be an error at the other place in the code if it reenables a UI
element without checking if it was disabled for other reasons, but I don't think
that happens (most of the time, elements are just disabled, and in that case
|reenable| defaults to the right value).
I think this is at least correct in more cases than the current behaviour, where
we don't reenable elements at all if they become unmanaged. If there are cases
where we wrongly reenable elements from other places, we should identify and fix
them separately.

[Evan Stade, 2011/07/07 21:09:16]

but how could the code check if it were disabled for other reasons? That fact
isn't stored anywhere, except in 'reenable', and from outside the context of
this function that would be a pretty opaque name. Maybe change the name to
notUserControlled or something
I don't know how likely it is to run into this in the wild, so while I agree, I
do not think we should wait for bug reports to roll in.

+    el.reenable = event.value['disabled'];
   }
 
   /////////////////////////////////////////////////////////////////////////////