Add a custom element to own structure of shadow DOM plugin placeholders.

Source/core/html/shadow/PluginPlaceholderElement.js

Index: Source/core/html/shadow/PluginPlaceholderElement.js
diff --git a/Source/core/html/shadow/PluginPlaceholderElement.js b/Source/core/html/shadow/PluginPlaceholderElement.js
new file mode 100644
index 0000000000000000000000000000000000000000..23c0202044bd5e3748dffe38d3665c6238dc719d
--- /dev/null
+++ b/Source/core/html/shadow/PluginPlaceholderElement.js
@@ -0,0 +1,46 @@
+// 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.
+
+'use strict';
+
+installClass('PluginPlaceholderElement', function(PluginPlaceholderElementPrototype) {
+    PluginPlaceholderElementPrototype.initializePlaceholderElements = function() {
+        // Produces DOM roughly equivalent to the following HTML:
+        //
+        // <div id="plugin-placeholder">
+        //   <div id="plugin-placeholder-content">
+        //     <div id="plugin-placeholder-message"></div>
+        //   </div>
+        // </div>
+        //
+        // FIXME: Move style out of script and into CSS.

[haraken, 2014/08/31 14:53:34]

This is something Blink-in-JS needs to support. Do you have any preference about
how Blink-in-JS supports CSS?

[jbroman, 2014/08/31 16:53:50]

The simplest approach for my needs so far (and PhistucK has already discovered)
is prototyped here:
https://codereview.chromium.org/516273002/

I'm not certain what the best approach is, but it seems to me that it's
necessary for Blink-in-JS to have some capacity for loading style (and possibly
image resources, though -webkit-appearance could be used), regardless of the
document's content security policy.

I think it's convenient for this to be stored in a separate .css file, either
next to the .js file or in core/css/.

[haraken, 2014/09/01 00:47:38]

Yes, I believe this is a right way to go. I'll comment on the CSS CL for more
details.

+
+        this.id = 'plugin-placeholder';
+        this.style.width = '100%';
+        this.style.height = '100%';
+        this.style.overflow = 'hidden';
+        this.style.display = 'flex';
+        this.style.alignItems = 'center';
+        this.style.backgroundColor = 'gray';
+        this.style.font = '12px -webkit-control';
+
+        var contentElement = document.createElement('div');
+        contentElement.id = 'plugin-placeholder-content';
+        contentElement.style.textAlign = 'center';
+        contentElement.style.margin = 'auto';
+
+        var messageElement = document.createElement('div');
+        messageElement.id = 'plugin-placeholder-message';
+
+        contentElement.appendChild(messageElement);
+        this.appendChild(contentElement);
+
+        this.messageElement = messageElement;
+    };
+
+    Object.defineProperty(PluginPlaceholderElementPrototype, 'message', {
+        get: function() { return this.messageElement.innerHTML; },
+        set: function(html) { this.messageElement.innerHTML = html; },

[haraken, 2014/08/31 14:53:34]

What happens if |html| contains <script> tags? Isn't there any risk of XSS?

[jbroman, 2014/08/31 16:53:50]

It should not be possible for author script to reach here; this should only be
supplied by the user agent (in this case, that will ultimately be the embedder,
though that's not plumbed through yet). My initial intention had been to only
accept plain text, but the current plugin placeholders also allow the user to
click on a link, so my current goal is for the embedder to supply plain text
only with simple links. For example:

  This plugin is disabled. Open <a href="#"
id="chrome-plugin-settings">chrome://plugins</a> to re-enable it.

I would then have a click event listener which would prevent the default action
on click, and dispatch that through to the embedder, which is empowered to take
that action.

It is true that this will require the embedder to escape any untrusted strings
that it may insert into the HTML, or for this private script to locally apply a
more restrictive CSP (that prevents inline style/scripts).

[jbroman, 2014/08/31 19:00:51]

Though now that this is in JavaScript, the possibility of accepting some very
limited templating language rather than raw HTML is probably easier than it
would be in C++. So the option of taking syntax like "Open
[chrome://plugins][chrome-plugin-settings] to re-enable it." and then turning
that into DOM in private script also exists.

[haraken, 2014/09/01 00:47:38]

I'm not familiar with how the plugin placeholder element should be implemented,
so I'll delegate the decision to experts.

+    });
+});