Port first garden-o-matic component over to polymer

Port first garden-o-matic component over to polymer

1. Add polymer bower json and update app.yaml appropriately.
2. Add 'unsafe-inline' to script-src so that imports work.
3. Add a load warning if you try to load the page without having
ever synced polymer.
4. Convert ui.results.Comparison over to <results-comparison> and
cleanup all code in ui.results.ResultsGrid.

Put results-comparison in it's own file. It makes sense to
put each custom element definition in it's own file and to test it
independently.

Add a top-level ui directory for all the UI related components. When we're
done, we should be able to delete a bunch of the JS files in the scripts
directory and all the CSS files in the styles directory.

NOTRY=true

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=176805

[ojan, 2014-06-21 21:34:42]

https://codereview.chromium.org/350563002/diff/1/Tools/GardeningServer/garden...
File Tools/GardeningServer/garden-o-matic.html (right):

https://codereview.chromium.org/350563002/diff/1/Tools/GardeningServer/garden...
Tools/GardeningServer/garden-o-matic.html:32: script-src 'self' file:
https://ajax.googleapis.com 'unsafe-inline';
This is the only line changed. For the others, I just got sick of dealing with
the random indenting that these had before.

[abarth-chromium, 2014-06-22 00:17:34]

> Add 'unsafe-inline' to script-src so that imports work.

Why is this necessary to make imports work?  I thought we decided that imports
could run inline script even if the main document didn't have unsafe-inline.

[ojan, 2014-06-22 00:27:49]

On 2014/06/22 at 00:17:34, abarth wrote:
> > Add 'unsafe-inline' to script-src so that imports work.
> 
> Why is this necessary to make imports work?  I thought we decided that imports
could run inline script even if the main document didn't have unsafe-inline.

I think that makes sense, but I don't think that's how it works today. You also
need to only allow it for parser inserted scripts in imports, right? Otherwise
you can always create a script element, set textContent and append it to the
page.

[abarth-chromium, 2014-06-22 01:11:04]

On 2014/06/22 at 00:27:49, ojan wrote:
> I think that makes sense, but I don't think that's how it works today. You
also need to only allow it for parser inserted scripts in imports, right?
Otherwise you can always create a script element, set textContent and append it
to the page.

The plan, as I understood it, was to control loading HTML imports with
script-src but then have the CSP for the imported document be controlled by the
document itself (e.g., by the HTTP headers that accompany it).  That's similar
to how iframes work.

Maybe things changed in spec land?

In any case, if you're going to add 'unsafe-inline' to GOM's CSP, you might as
well just delete the CSP policy entirely.  That's a fine product decision to
make if we're not worried about the security of this tool.  I originally added
CSP to GOM not because I was worried about security but because I wanted to
dogfood CSP.  CSP is mature enough at this point that we don't need to dogfood
it in GOM (although it's telling us something interesting about the interaction
between CSP and imports).

[ojan, 2014-06-22 01:25:50]

On 2014/06/22 at 01:11:04, abarth wrote:
> On 2014/06/22 at 00:27:49, ojan wrote:
> > I think that makes sense, but I don't think that's how it works today. You
also need to only allow it for parser inserted scripts in imports, right?
Otherwise you can always create a script element, set textContent and append it
to the page.
> 
> The plan, as I understood it, was to control loading HTML imports with
script-src but then have the CSP for the imported document be controlled by the
document itself (e.g., by the HTTP headers that accompany it).  That's similar
to how iframes work.
> 
> Maybe things changed in spec land?
> 
> In any case, if you're going to add 'unsafe-inline' to GOM's CSP, you might as
well just delete the CSP policy entirely.  That's a fine product decision to
make if we're not worried about the security of this tool.  I originally added
CSP to GOM not because I was worried about security but because I wanted to
dogfood CSP.  CSP is mature enough at this point that we don't need to dogfood
it in GOM (although it's telling us something interesting about the interaction
between CSP and imports).

Right. I was tempted to just delete it, but I feel like we need to solve this
CSP+imports thing and this is as good an impetus to do so as any. But I didn't
want to block making forward progress here on that.

I can do either way. I don't feel strongly.

[ojan, 2014-06-22 01:27:17]

On 2014/06/22 at 01:25:50, OOO-only-code-yellow-reviews wrote:
> On 2014/06/22 at 01:11:04, abarth wrote:
> > On 2014/06/22 at 00:27:49, ojan wrote:
> > > I think that makes sense, but I don't think that's how it works today. You
also need to only allow it for parser inserted scripts in imports, right?
Otherwise you can always create a script element, set textContent and append it
to the page.
> > 
> > The plan, as I understood it, was to control loading HTML imports with
script-src but then have the CSP for the imported document be controlled by the
document itself (e.g., by the HTTP headers that accompany it).  That's similar
to how iframes work.
> > 
> > Maybe things changed in spec land?
> > 
> > In any case, if you're going to add 'unsafe-inline' to GOM's CSP, you might
as well just delete the CSP policy entirely.  That's a fine product decision to
make if we're not worried about the security of this tool.  I originally added
CSP to GOM not because I was worried about security but because I wanted to
dogfood CSP.  CSP is mature enough at this point that we don't need to dogfood
it in GOM (although it's telling us something interesting about the interaction
between CSP and imports).
> 
> Right. I was tempted to just delete it, but I feel like we need to solve this
CSP+imports thing and this is as good an impetus to do so as any. But I didn't
want to block making forward progress here on that.
> 
> I can do either way. I don't feel strongly.

It is the case that we don't care about XSS on this page IMO, but I like the
idea of pushing forward CSP+imports.

[abarth-chromium, 2014-06-22 03:23:29]

On 2014/06/22 at 01:27:17, ojan wrote:
> It is the case that we don't care about XSS on this page IMO, but I like the
idea of pushing forward CSP+imports.

Let's delete the CSP from GOM and file a bug to follow up about CSP and imports.

[ojan, 2014-06-22 03:46:30]

On 2014/06/22 at 03:23:29, abarth wrote:
> On 2014/06/22 at 01:27:17, ojan wrote:
> > It is the case that we don't care about XSS on this page IMO, but I like the
idea of pushing forward CSP+imports.
> 
> Let's delete the CSP from GOM and file a bug to follow up about CSP and
imports.

Done and done. https://code.google.com/p/chromium/issues/detail?id=387421

[esprehn, 2014-06-22 05:15:20]

https://codereview.chromium.org/350563002/diff/40001/Tools/GardeningServer/ga...
File Tools/GardeningServer/garden-o-matic.html (right):

https://codereview.chromium.org/350563002/diff/40001/Tools/GardeningServer/ga...
Tools/GardeningServer/garden-o-matic.html:43: <link rel='import'
href="bower_components/polymer/polymer.html">
Maybe be consistent and use double quotes here?

https://codereview.chromium.org/350563002/diff/40001/Tools/GardeningServer/ru...
File Tools/GardeningServer/run-unittests.html (right):

https://codereview.chromium.org/350563002/diff/40001/Tools/GardeningServer/ru...
Tools/GardeningServer/run-unittests.html:77: <link rel='import'
href="ui/results-comparison-tests.html">
ditto

https://codereview.chromium.org/350563002/diff/40001/Tools/GardeningServer/ui...
File Tools/GardeningServer/ui/results-comparison-tests.html (right):

https://codereview.chromium.org/350563002/diff/40001/Tools/GardeningServer/ui...
Tools/GardeningServer/ui/results-comparison-tests.html:7: <link rel='import'
href="results-comparison.html">
ditto

https://codereview.chromium.org/350563002/diff/40001/Tools/GardeningServer/ui...
Tools/GardeningServer/ui/results-comparison-tests.html:12:
module("results-comparison");
What is this?

https://codereview.chromium.org/350563002/diff/40001/Tools/GardeningServer/ui...
Tools/GardeningServer/ui/results-comparison-tests.html:47: // all the data
changes. Is there a better way?
Platform.endOfMicrotask(fn). I wouldn't use setTimeout.

https://codereview.chromium.org/350563002/diff/40001/Tools/GardeningServer/ui...
Tools/GardeningServer/ui/results-comparison-tests.html:99: // but that happens
at microtask time, so there's no way to catch it.
What update step throws errors?

https://codereview.chromium.org/350563002/diff/40001/Tools/GardeningServer/ui...
File Tools/GardeningServer/ui/results-comparison.html (right):

https://codereview.chromium.org/350563002/diff/40001/Tools/GardeningServer/ui...
Tools/GardeningServer/ui/results-comparison.html:7: <polymer-element
name="results-comparison" attributes="type urlsByKind">
You should really pick a prefix for your app and use it on all your components.
I might suggest "gm-"

https://codereview.chromium.org/350563002/diff/40001/Tools/GardeningServer/ui...
Tools/GardeningServer/ui/results-comparison.html:63: result =
document.createElement('img');
This can actually be new Image() and the below one can be new Audio() if you
want.

https://codereview.chromium.org/350563002/diff/40001/Tools/GardeningServer/ui...
Tools/GardeningServer/ui/results-comparison.html:68: result =
document.createElement('iframe');
else if (this.type == == results.kIframeType) ?

Otherwise that kUndefinedType creates iframes.

Note that a somewhat more idiomatic JS way would be to use a table of functions.
It probably performs slightly better too, but this widget isn't so common that
it matters.

var constructors = {
  "image": function() {
     return new Image();
  },
  "audio": function() {
    ...
  },
  ...
}

and this becomes one line with:

result = constructors[type]();

[ojan, 2014-06-22 06:33:19]

https://codereview.chromium.org/350563002/diff/40001/Tools/GardeningServer/ui...
File Tools/GardeningServer/ui/results-comparison-tests.html (right):

https://codereview.chromium.org/350563002/diff/40001/Tools/GardeningServer/ui...
Tools/GardeningServer/ui/results-comparison-tests.html:12:
module("results-comparison");
This is just the name of the test suite. Makes it easier to see what's going on
in the test harness, e.g. the first test below's name would be
results-comparison.text.

https://codereview.chromium.org/350563002/diff/40001/Tools/GardeningServer/ui...
Tools/GardeningServer/ui/results-comparison-tests.html:99: // but that happens
at microtask time, so there's no way to catch it.
The actual _update method in results-comparison throws an error if you give it
invalid input.

https://codereview.chromium.org/350563002/diff/40001/Tools/GardeningServer/ui...
File Tools/GardeningServer/ui/results-comparison.html (right):

https://codereview.chromium.org/350563002/diff/40001/Tools/GardeningServer/ui...
Tools/GardeningServer/ui/results-comparison.html:7: <polymer-element
name="results-comparison" attributes="type urlsByKind">
Yeah, I started with gom-results-comparison, but that seemed so wordy.

https://codereview.chromium.org/350563002/diff/40001/Tools/GardeningServer/ui...
Tools/GardeningServer/ui/results-comparison.html:63: result =
document.createElement('img');
Why is that better? Seems better to me to use document.createElement for
everything than to use constructors for some things and createElement for
others.

[abarth-chromium, 2014-06-22 14:43:51]

https://codereview.chromium.org/350563002/diff/40001/.gitignore
File .gitignore (right):

https://codereview.chromium.org/350563002/diff/40001/.gitignore#newcode5
.gitignore:5: Tools/GardeningServer/bower_components
This should go in Tools/GardeningServer/.gitignore

https://codereview.chromium.org/350563002/diff/40001/Tools/GardeningServer/ui...
File Tools/GardeningServer/ui/results-comparison.html (right):

https://codereview.chromium.org/350563002/diff/40001/Tools/GardeningServer/ui...
Tools/GardeningServer/ui/results-comparison.html:7: <polymer-element
name="results-comparison" attributes="type urlsByKind">
Yeah, we need a prefix.  Don't worry about it being wordy.  We can rename things
as we go.

https://codereview.chromium.org/350563002/diff/40001/Tools/GardeningServer/ui...
Tools/GardeningServer/ui/results-comparison.html:77: },
Why not use <template> to do this work?  You're re-implementing MDV.

[ojan, 2014-06-22 22:49:22]

https://codereview.chromium.org/350563002/diff/40001/.gitignore
File .gitignore (right):

https://codereview.chromium.org/350563002/diff/40001/.gitignore#newcode5
.gitignore:5: Tools/GardeningServer/bower_components
Somehow I forgot that you could do nested .gitignore files.

https://codereview.chromium.org/350563002/diff/40001/Tools/GardeningServer/ga...
File Tools/GardeningServer/garden-o-matic.html (right):

https://codereview.chromium.org/350563002/diff/40001/Tools/GardeningServer/ga...
Tools/GardeningServer/garden-o-matic.html:43: <link rel='import'
href="bower_components/polymer/polymer.html">
Done.

https://codereview.chromium.org/350563002/diff/40001/Tools/GardeningServer/ru...
File Tools/GardeningServer/run-unittests.html (right):

https://codereview.chromium.org/350563002/diff/40001/Tools/GardeningServer/ru...
Tools/GardeningServer/run-unittests.html:77: <link rel='import'
href="ui/results-comparison-tests.html">
Done.

https://codereview.chromium.org/350563002/diff/40001/Tools/GardeningServer/ui...
File Tools/GardeningServer/ui/results-comparison-tests.html (right):

https://codereview.chromium.org/350563002/diff/40001/Tools/GardeningServer/ui...
Tools/GardeningServer/ui/results-comparison-tests.html:7: <link rel='import'
href="results-comparison.html">
done.

https://codereview.chromium.org/350563002/diff/40001/Tools/GardeningServer/ui...
Tools/GardeningServer/ui/results-comparison-tests.html:12:
module("results-comparison");
Alternately, we could do this manually, e.g.
asyncTest("results-comparison.text", ...).

https://codereview.chromium.org/350563002/diff/40001/Tools/GardeningServer/ui...
Tools/GardeningServer/ui/results-comparison-tests.html:47: // all the data
changes. Is there a better way?
Done.

https://codereview.chromium.org/350563002/diff/40001/Tools/GardeningServer/ui...
Tools/GardeningServer/ui/results-comparison-tests.html:99: // but that happens
at microtask time, so there's no way to catch it.
In either case, it's gone now.

https://codereview.chromium.org/350563002/diff/40001/Tools/GardeningServer/ui...
File Tools/GardeningServer/ui/results-comparison.html (right):

https://codereview.chromium.org/350563002/diff/40001/Tools/GardeningServer/ui...
Tools/GardeningServer/ui/results-comparison.html:7: <polymer-element
name="results-comparison" attributes="type urlsByKind">
At esprehns suggestion, I went with ct- for chromium tools. I think eventually
we want most of these widgets to be shared across dashboards and I'm not too
worried about naming conflicts within the chromium tools themselves. In the rare
cases where they happen, they can easily be worked around.

https://codereview.chromium.org/350563002/diff/40001/Tools/GardeningServer/ui...
Tools/GardeningServer/ui/results-comparison.html:63: result =
document.createElement('img');
This is also gone now.

https://codereview.chromium.org/350563002/diff/40001/Tools/GardeningServer/ui...
Tools/GardeningServer/ui/results-comparison.html:77: },
Lol. Just wasn't thinking as I copy-pasted the code over.

https://codereview.chromium.org/350563002/diff/60001/Tools/GardeningServer/sc...
File Tools/GardeningServer/scripts/ui/results.js (right):

https://codereview.chromium.org/350563002/diff/60001/Tools/GardeningServer/sc...
Tools/GardeningServer/scripts/ui/results.js:62: comparison.setAttribute('type',
resultType);
All these setAttributes are kind of gross, but will go away when we switch
ResultsGrid over to polymer.

[esprehn, 2014-06-23 05:25:05]

You put GOM into quirks mode, don't do that :(

https://codereview.chromium.org/350563002/diff/80001/Tools/GardeningServer/ga...
File Tools/GardeningServer/garden-o-matic.html (right):

https://codereview.chromium.org/350563002/diff/80001/Tools/GardeningServer/ga...
Tools/GardeningServer/garden-o-matic.html:29: <!DOCTYPE html>
You can't put a comment before the doctype, that causes quirks mode.

https://codereview.chromium.org/350563002/diff/80001/Tools/GardeningServer/ru...
File Tools/GardeningServer/run-unittests.html (right):

https://codereview.chromium.org/350563002/diff/80001/Tools/GardeningServer/ru...
Tools/GardeningServer/run-unittests.html:26: <!DOCTYPE html>
Ditto, you can't do this.

https://codereview.chromium.org/350563002/diff/80001/Tools/GardeningServer/sc...
File Tools/GardeningServer/scripts/ui/results.js (right):

https://codereview.chromium.org/350563002/diff/80001/Tools/GardeningServer/sc...
Tools/GardeningServer/scripts/ui/results.js:65:
comparison.setAttribute('actualUrl', resultsURLsByKind[results.kActualKind]);
Polymer is going to create properties for you, you don't need to use attrs.

.actualUrl = ...;

.expectedUrl = ...;

don't use setAttribute.

https://codereview.chromium.org/350563002/diff/80001/Tools/GardeningServer/ui...
File Tools/GardeningServer/ui/ct-results-comparison.html (right):

https://codereview.chromium.org/350563002/diff/80001/Tools/GardeningServer/ui...
Tools/GardeningServer/ui/ct-results-comparison.html:36: <template if="{{type ==
_kImageType && _urlForKind(resultKind)}}">
This is a very contorted way to do this. You really just want two different
components I think. All this _urlForKind stuff and the loop is very weird usage
of MDV and components.

https://codereview.chromium.org/350563002/diff/80001/Tools/GardeningServer/ui...
Tools/GardeningServer/ui/ct-results-comparison.html:50: Polymer({
You need to initialize your properties you've set to data bind to attrs to
default values here.

[ojan, 2014-06-23 05:43:33]

https://codereview.chromium.org/350563002/diff/80001/Tools/GardeningServer/ga...
File Tools/GardeningServer/garden-o-matic.html (right):

https://codereview.chromium.org/350563002/diff/80001/Tools/GardeningServer/ga...
Tools/GardeningServer/garden-o-matic.html:29: <!DOCTYPE html>
On 2014/06/23 05:25:04, esprehn wrote:
> You can't put a comment before the doctype, that causes quirks mode.

False.

I prefer all the real content being below the license.

https://codereview.chromium.org/350563002/diff/80001/Tools/GardeningServer/sc...
File Tools/GardeningServer/scripts/ui/results.js (right):

https://codereview.chromium.org/350563002/diff/80001/Tools/GardeningServer/sc...
Tools/GardeningServer/scripts/ui/results.js:65:
comparison.setAttribute('actualUrl', resultsURLsByKind[results.kActualKind]);
On 2014/06/23 05:25:05, esprehn wrote:
> Polymer is going to create properties for you, you don't need to use attrs.
> 
> .actualUrl = ...;
> 
> .expectedUrl = ...;
> 
> don't use setAttribute.

I was picturing after ResultsGrid was converted to a polymer element that these
would need to be real attributes anyways and this forces the values to be
strings. Before I was using a property value that was an object, which won't
work when this is converted to a polymer element.

I can change it to properties if you want, but this code will be going away
entirely shortly anyways.

https://codereview.chromium.org/350563002/diff/80001/Tools/GardeningServer/ui...
File Tools/GardeningServer/ui/ct-results-comparison.html (right):

https://codereview.chromium.org/350563002/diff/80001/Tools/GardeningServer/ui...
Tools/GardeningServer/ui/ct-results-comparison.html:36: <template if="{{type ==
_kImageType && _urlForKind(resultKind)}}">
On 2014/06/23 05:25:05, esprehn wrote:
> This is a very contorted way to do this. You really just want two different
> components I think. All this _urlForKind stuff and the loop is very weird
usage
> of MDV and components.

I'm not sure what you're suggesting I do. What would the two components do? The
_urlForKind check is so that we don't create the element if that attribute
wasn't set. The one below is obviously to get the right attribute's value.

https://codereview.chromium.org/350563002/diff/80001/Tools/GardeningServer/ui...
Tools/GardeningServer/ui/ct-results-comparison.html:50: Polymer({
On 2014/06/23 05:25:05, esprehn wrote:
> You need to initialize your properties you've set to data bind to attrs to
> default values here.

Why? It seems to work without. Not disagreeing, just trying to understand how
polymer works better.

[esprehn, 2014-06-23 06:06:00]

On 2014/06/23 at 05:43:33, ojan wrote:
>
https://codereview.chromium.org/350563002/diff/80001/Tools/GardeningServer/ga...
> File Tools/GardeningServer/garden-o-matic.html (right):
> 
>
https://codereview.chromium.org/350563002/diff/80001/Tools/GardeningServer/ga...
> Tools/GardeningServer/garden-o-matic.html:29: <!DOCTYPE html>
> On 2014/06/23 05:25:04, esprehn wrote:
> > You can't put a comment before the doctype, that causes quirks mode.
> 
> False.
> 
> I prefer all the real content being below the license.

Truth, but apparently only in IE9 and below:

"Make sure you put the DOCTYPE right at the beginning of your HTML document.
Anything before the DOCTYPE, like a comment or an XML declaration will trigger
quirks mode in Internet Explorer 9 and older." per
https://developer.mozilla.org/en-US/docs/Quirks_Mode_and_Standards_Mode

I guess blink never did that and we don't care about older browsers.

> 
>
https://codereview.chromium.org/350563002/diff/80001/Tools/GardeningServer/sc...
> File Tools/GardeningServer/scripts/ui/results.js (right):
> 
>
https://codereview.chromium.org/350563002/diff/80001/Tools/GardeningServer/sc...
> Tools/GardeningServer/scripts/ui/results.js:65:
comparison.setAttribute('actualUrl', resultsURLsByKind[results.kActualKind]);
> On 2014/06/23 05:25:05, esprehn wrote:
> > Polymer is going to create properties for you, you don't need to use attrs.
> > 
> > .actualUrl = ...;
> > 
> > .expectedUrl = ...;
> > 
> > don't use setAttribute.
> 
> I was picturing after ResultsGrid was converted to a polymer element that
these would need to be real attributes anyways and this forces the values to be
strings. Before I was using a property value that was an object, which won't
work when this is converted to a polymer element.
> 
> I can change it to properties if you want, but this code will be going away
entirely shortly anyways.
> 

I don't understand. Nothing ever has to be attributes, why do you think they
need to be?

>
https://codereview.chromium.org/350563002/diff/80001/Tools/GardeningServer/ui...
> File Tools/GardeningServer/ui/ct-results-comparison.html (right):
> 
>
https://codereview.chromium.org/350563002/diff/80001/Tools/GardeningServer/ui...
> Tools/GardeningServer/ui/ct-results-comparison.html:36: <template if="{{type
== _kImageType && _urlForKind(resultKind)}}">
> On 2014/06/23 05:25:05, esprehn wrote:
> > This is a very contorted way to do this. You really just want two different
> > components I think. All this _urlForKind stuff and the loop is very weird
usage
> > of MDV and components.
> 
> I'm not sure what you're suggesting I do. What would the two components do?
The _urlForKind check is so that we don't create the element if that attribute
wasn't set. The one below is obviously to get the right attribute's value.

What's the actual purpose of this component? Does it really ever have all the
combinations of urls? Having to loop over these constants like this is very
weird.

> 
>
https://codereview.chromium.org/350563002/diff/80001/Tools/GardeningServer/ui...
> Tools/GardeningServer/ui/ct-results-comparison.html:50: Polymer({
> On 2014/06/23 05:25:05, esprehn wrote:
> > You need to initialize your properties you've set to data bind to attrs to
> > default values here.
> 
> Why? It seems to work without. Not disagreeing, just trying to understand how
polymer works better.

Polymer is guessing at your types, so is v8. If you don't start with all the
properties you'll ever have all your instances are different in v8 (and other
browsers) and polymer can't guess the types. You should always start with all
possible properties on classes.

[michaelpg, 2014-06-24 01:15:39]

https://codereview.chromium.org/350563002/diff/80001/Tools/GardeningServer/po...
File Tools/GardeningServer/polymer-load-warning.html (right):

https://codereview.chromium.org/350563002/diff/80001/Tools/GardeningServer/po...
Tools/GardeningServer/polymer-load-warning.html:9: alert('Polymer did not load
correctly. Did you run "bower update"?');
+" from Tools/GardeningServer"

[ojan, 2014-06-24 02:41:17]

All comments should be addressed.

https://codereview.chromium.org/350563002/diff/80001/Tools/GardeningServer/po...
File Tools/GardeningServer/polymer-load-warning.html (right):

https://codereview.chromium.org/350563002/diff/80001/Tools/GardeningServer/po...
Tools/GardeningServer/polymer-load-warning.html:9: alert('Polymer did not load
correctly. Did you run "bower update"?');
On 2014/06/24 01:15:39, Michael Giuffrida wrote:
> +" from Tools/GardeningServer"

Good point. Done.

[esprehn, 2014-06-24 03:01:55]

lgtm

[ojan, 2014-06-24 03:02:58]

The CQ bit was checked by ojan@chromium.org

[commit-bot: I haz the power, 2014-06-24 03:03:59]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/ojan@chromium.org/350563002/160001

[commit-bot: I haz the power, 2014-06-24 03:04:44]

Change committed as 176805