MD WebUI: Add shared cr-toolbar element

chrome/test/data/webui/md_history/history_toolbar_test.js

Index: chrome/test/data/webui/md_history/history_toolbar_test.js
diff --git a/chrome/test/data/webui/md_history/history_toolbar_test.js b/chrome/test/data/webui/md_history/history_toolbar_test.js
index cb0758212114b571e9053fc3306a6b7d85f80bf5..982eee8970756bf22cbf8ea7fb58a5acddbf8114 100644
--- a/chrome/test/data/webui/md_history/history_toolbar_test.js
+++ b/chrome/test/data/webui/md_history/history_toolbar_test.js
@@ -53,16 +53,15 @@ cr.define('md_history.history_toolbar_test', function() {
 
       test('more from this site sends and sets correct data', function(done) {
         registerMessageCallback('queryHistory', this, function (info) {

[dpapad, 2016/05/18 23:39:13]

FYI, we have established the "browser proxy" pattern in the MD settings code,
that makes testing much easier (using a "test proxy") than using the "hacky"
registerMessageCallback method. I would gladly send you some examples and help
you convert md_history to use that pattern if you are interested.

[tsergeant, 2016/05/19 07:11:55]

Cool, I'd be interested to know more.

-          assertEquals(info[0], 'example.com');
+          assertEquals('example.com', info[0]);
           flush(function() {

[dpapad, 2016/05/18 23:39:13]

Unrelated to this CL, how about making flush() return a Promise, instead of
expecting a callback and using window.setTimeout(). Promises also yield to the
message loop and are more flexible API-wise

flush().then(function() {
  assertEquals('example.com', toolbar.$['main-toolbar'].getValue());
  done();
});

[tsergeant, 2016/05/19 07:11:55]

calamity@ and I talked about this yesterday, actually. I'll do this in a
follow-up change.

-            assertEquals(toolbar.$$('#search-input').$$('#search-input').value,
-                'example.com');
+            assertEquals('example.com', toolbar.$['main-toolbar'].getValue());
             done();
           });
         });
 
         element.$.sharedMenu.itemData = {domain: 'example.com'};
-        MockInteractions.tap(element.$.menuMoreButton);
+        element.onMoreFromSiteTap_();

[dpapad, 2016/05/18 23:39:13]

Simulating a tap action seems much better than calling a private method. Is
there any good reason for this change?

[tsergeant, 2016/05/19 07:11:55]

In a previous version of this patch, simulating a click event would cause the
toolbar to close and muck up the test. The toolbar closing behaviour has changed
since then, so it's no longer a problem, and I've changed this code back.

       });
 
       teardown(function() {