Move plugin placeholder style to CSS, and allow it to bypass main world CSP.

Source/core/frame/WindowPrivateScript.idl

Index: Source/core/frame/WindowPrivateScript.idl
diff --git a/Source/core/frame/WindowPrivateScript.idl b/Source/core/frame/WindowPrivateScript.idl
new file mode 100644
index 0000000000000000000000000000000000000000..de2845226f5b12c4b833a853bd08665f28df0a12
--- /dev/null
+++ b/Source/core/frame/WindowPrivateScript.idl
@@ -0,0 +1,12 @@
+// Copyright 2014 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.
+
+// Utility methods exposed only to private script.
+[
+    NoInterfaceObject, // Always used as target of 'implements'
+] interface WindowPrivateScript {
+    // FIXME: Get rid of this, and use something more elegant instead.
+    // http://crbug.com/414849
+    [OnlyExposedToPrivateScript] DOMString loadPlatformResource(DOMString name);

[haraken, 2014/10/04 00:56:20]

Will we be able to use this API to load images, javascript etc, not limited to
css?

[jbroman, 2014/10/04 03:36:06]

Since it returns a string, I don't think it would be suitable for images. I
don't think this is ultimately the best approach for this reason, and the fact
that it doesn't facilitate resolution of dependent resources (e.g. images in
stylesheets); see crbug.com/414849. Perhaps a parallel one could produce a data
URL, but I'm hoping this will be short-lived.

[haraken, 2014/10/05 23:54:39]

Yeah, if the loadPlatformResource API doesn't facilitate resolution of dependent
resources, we need rethink about the API.

Whats's the "parallel one"?

I don't quite follow the discussion in crbug.com/414849, but did you give up the
"chrome-resource://" approach? (I guess the "chrome-resource://" approach will
resolve dependent resources as well.)

+};