chrome://settings - Provide method for pages to prevent themselves being shown.

chrome/browser/resources/options/add_startup_page_overlay.js

Index: chrome/browser/resources/options/add_startup_page_overlay.js
diff --git a/chrome/browser/resources/options/add_startup_page_overlay.js b/chrome/browser/resources/options/add_startup_page_overlay.js
index 6e9e1b26e7c73ee6364f70b783e438fc8ce00ef6..5e33005482dcefb42af513fa8efd647585d79c19 100644
--- a/chrome/browser/resources/options/add_startup_page_overlay.js
+++ b/chrome/browser/resources/options/add_startup_page_overlay.js
@@ -111,6 +111,11 @@ cr.define('options', function() {
       $('addStartupPageURL').value = url;
       this.updateAddButtonState_();
     },
+
+    /** @inheritDoc */
+    canShowPage: function() {
+      return !$('startupAddButton').disabled;

[stuartmorgan, 2011/02/12 01:09:06]

I'm not wild on using UI state for this. How about a "static" method on the
Browser page object that returns whether or not it should be enabled, and base
both this and the UI state updating on that method?

[Evan Stade, 2011/02/12 03:06:42]

There is already such a function, called
shouldEnableCustomStartupPageControls_(), and it also relies on "UI state". I
will use it here.

The scare quotes there indicate that I don't think this is UI state. I believe
this attribute is logically meaningful. The details of how it is represented in
the UI are abstracted (it happens to be greyed out, but that could be changed
with css right?). My point being, I believe that
shouldEnableCustomStartupPageControls_ is ok, even though it seems to contradict
the spirit of your comment.

+    },
   };
 
   AddStartupPageOverlay.updateRecentPageList = function(pages) {