Check and canonicalize CSS selectors before registering PageStateMatchers.

chrome/renderer/resources/extensions/declarative_content_custom_bindings.js

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 // Custom binding for the declarativeContent API.
 
 var binding = require('binding').Binding.create('declarativeContent');
 
 var utils = require('utils');
 var validate = require('schemaUtils').validate;
@@ skipping 17 matching lines @@
     for (var key in parameters) {
       if ($Object.hasOwnProperty(parameters, key)) {
         instance[key] = parameters[key];
       }
     }
     instance.instanceType = 'declarativeContent.' + typeId;
     var schema = getSchema(typeId);
     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');
   };
 });
 
 exports.binding = binding.generate();