Check and canonicalize CSS selectors before registering PageStateMatchers.

chrome/renderer/resources/extensions/declarative_content_custom_bindings.js

Index: chrome/renderer/resources/extensions/declarative_content_custom_bindings.js
diff --git a/chrome/renderer/resources/extensions/declarative_content_custom_bindings.js b/chrome/renderer/resources/extensions/declarative_content_custom_bindings.js
index beb5409e7baab66667f49f3452b5615f13bb8f99..5652ca88864eccad780cfa3dc0563bac97e6e526 100644
--- a/chrome/renderer/resources/extensions/declarative_content_custom_bindings.js
+++ b/chrome/renderer/resources/extensions/declarative_content_custom_bindings.js
@@ -35,9 +35,35 @@ binding.registerCustomHook( function(api) {
     validate([instance], [schema]);
   }
 
+  function canonicalizeCssSelectors(selectors) {
+    var div = document.createElement('div');
+    div.innerHTML = '<style scoped></style>';
+    document.body.appendChild(div);

[not at google - send to devlin, 2013/08/27 01:46:14]

Modifying the page's DOM / exposing our internals to the page makes me nervous,
though a lot less nervous than if this were actually a web page (as opposed to
an extension background page). I could rattle off a whole bunch of worrying
things with the former. In any case it really saddens me that this is the only
way to canonicalize CSS; it's our platform; indeed, building this as an API call
into blink sounds better. What are the issues with that?

[Jeffrey Yasskin, 2013/08/27 19:09:48]

Note that this only exposes anything to the same extension that used
declarativeContent.PageStateMatcher.
Adding a C++ call to Blink just requires getting approval from those owners,
which they're reasonable about. Adding a true JS interface would be really hard,
of course.

I'll send them a CL adding the C++ function.

[not at google - send to devlin, 2013/08/27 19:39:53]

Yeah I know, but extensions still to unwittingly break themselves (I've fixed
enough such problems to be well aware of that). In particular libraries. I can
totally imagine some CSS library which compiles CSS style rules as they're added
and replaces them with something else (e.g. LESS, SASS, whatever). If that ends
up running in an extension context (e.g. say a popup) it might break things.
Cool.

[Jeffrey Yasskin, 2013/08/29 03:39:39]

Done: https://codereview.chromium.org/23659002/

+    try {
+      var sheet = document.styleSheets[document.styleSheets.length - 1];
+      for (var i = 0; i < selectors.length; i++) {
+        try {
+          sheet.insertRule(selectors[i] + '{}', 0);
+        } catch(e) {
+          if (e.name == "SyntaxError") {
+            throw new Error('Invalid selector: ' + selectors[i]);
+          }
+          throw e;
+        }
+        selectors[i] = sheet.cssRules[0].selectorText;
+        sheet.deleteRule(0);
+      }
+    } finally {
+      document.body.removeChild(div);
+    }
+  }
+
   // Setup all data types for the declarative content API.
   declarativeContent.PageStateMatcher = function(parameters) {
     setupInstance(this, parameters, 'PageStateMatcher');
+    if ('css' in this) {

[not at google - send to devlin, 2013/08/27 01:46:14]

small point, but hasOwnProperty is probably better here since we don't look up
the prototype chain for function calls.

[Jeffrey Yasskin, 2013/08/27 19:09:48]

Sure (haven't updated yet, but will). Where's the function call you're talking
about?

[not at google - send to devlin, 2013/08/27 19:39:53]

I mean, for all extension function calls (chrome.browserAction.whatever). We
don't look up the prototype.

[Jeffrey Yasskin, 2013/08/29 03:39:39]

Done.

+      canonicalizeCssSelectors(this.css);
+    }
   };
   declarativeContent.ShowPageAction = function(parameters) {
     setupInstance(this, parameters, 'ShowPageAction');