Enable SRI only for same origin and CORS content.

Enabled SRI only for same origin and CORS content.

According to the spec draft, Subresource Integrity should only work on
same origin or CORS enabled content. This is to avoid security issues
where SRI could be used to check the content of otherwise secret
cross-origin resources.

This CL modifies the script and style SRI checks to only be done on CORS
and same origin content. If an integrity attribute is present and
neither of those conditions hold, it adds a console warning. This
requires modifications to fetch and script loader to pass forward the
information that CORS has failed or the content is not same origin.

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

[jww, 2015-02-25 20:02:57]

jww@chromium.org changed reviewers:
+ mkwst@chromium.org

[jww, 2015-02-25 20:03:10]

Mike, can you take a look? Thanks!

[Mike West, 2015-02-26 08:44:53]

Thanks! Comments inline.

https://codereview.chromium.org/954233003/diff/1/Source/core/dom/ScriptLoader...
File Source/core/dom/ScriptLoader.cpp (right):

https://codereview.chromium.org/954233003/diff/1/Source/core/dom/ScriptLoader...
Source/core/dom/ScriptLoader.cpp:376:
contextDocument->addConsoleMessage(ConsoleMessage::create(SecurityMessageSource,
ErrorMessageLevel, "Cannot enforce integrity on non-CORS enabled resource."));
So we continue loading the resource if the CORS check fails? This isn't what we
do for other CORS-related checks, like `<script crossorigin>`... was this an
intentional decision? I'm willing to defer to the folks actually editing the
spec, but I'd like to know it was a conscious decision.

https://codereview.chromium.org/954233003/diff/1/Source/core/fetch/CSSStyleSh...
File Source/core/fetch/CSSStyleSheetResource.h (right):

https://codereview.chromium.org/954233003/diff/1/Source/core/fetch/CSSStyleSh...
Source/core/fetch/CSSStyleSheetResource.h:55: bool isCORSNeededAndFailed() const
{ return m_corsNeededAndFailed; }
"CORS needed" for what? CORS isn't needed to load the resource, it's only needed
for the SRI check, right? Can you rename this to something like
"eligibleForIntegrityValidation"? It might be worth pushing that all the way up
to Resource, actually; that might simplify the script check.

https://codereview.chromium.org/954233003/diff/1/Source/core/fetch/ResourceFe...
File Source/core/fetch/ResourceFetcher.cpp (right):

https://codereview.chromium.org/954233003/diff/1/Source/core/fetch/ResourceFe...
Source/core/fetch/ResourceFetcher.cpp:605: bool
ResourceFetcher::canAccessResource(Resource* resource, SecurityOrigin*
sourceOrigin, const KURL& url, bool logErrors) const
I'd prefer to replace this boolean with an enum so that it's clear at the
callsites.

https://codereview.chromium.org/954233003/diff/1/Source/core/fetch/ResourceFe...
Source/core/fetch/ResourceFetcher.cpp:622:
toCSSStyleSheetResource(resource)->setCORSNeededAndFailed();
It seems strange to set this as a side-effect of an access check. Perhaps you
could structure this as a property of Resource (e.g. pass in a SecurityOrigin,
and it tells you whether the algorithm in
https://w3c.github.io/webappsec/specs/subresourceintegrity/#is-resource-eligi...
returns true.

https://codereview.chromium.org/954233003/diff/1/Source/core/fetch/ResourceLo...
File Source/core/fetch/ResourceLoader.cpp (right):

https://codereview.chromium.org/954233003/diff/1/Source/core/fetch/ResourceLo...
Source/core/fetch/ResourceLoader.cpp:365: if (m_resource->type() ==
Resource::CSSStyleSheet && !m_host->canAccessResource(m_resource,
m_options.securityOrigin.get(), response.url(), false))
1. I think we should only do this check if we actually need to (e.g. if an
integrity attribute is present.

2. You don't need to `setCORSNeededAndFailed`, as it's done as a side-effect of
failing the `canAccessResource` check, isn't it? (Note: this is an argument for
restructuring the code, as this kind of side-effect is tough to follow).

https://codereview.chromium.org/954233003/diff/1/Source/core/html/HTMLLinkEle...
File Source/core/html/HTMLLinkElement.cpp (right):

https://codereview.chromium.org/954233003/diff/1/Source/core/html/HTMLLinkEle...
Source/core/html/HTMLLinkElement.cpp:513:
document().addConsoleMessage(ConsoleMessage::create(SecurityMessageSource,
ErrorMessageLevel, "Cannot enforce integrity on non-CORS enabled resource."));
Same question as I had with script: should we just allow the request? I don't
think that's actually what the spec says (e.g.
https://w3c.github.io/webappsec/specs/subresourceintegrity/#is-resource-eligi...
returns false, so
https://w3c.github.io/webappsec/specs/subresourceintegrity/#does-resource-mat...
returns false in step 2.

[jww, 2015-03-06 02:16:42]

Mike, thanks for the comments, all spot on. I think I've addressed them here.
Let me know what you think.

https://codereview.chromium.org/954233003/diff/1/Source/core/dom/ScriptLoader...
File Source/core/dom/ScriptLoader.cpp (right):

https://codereview.chromium.org/954233003/diff/1/Source/core/dom/ScriptLoader...
Source/core/dom/ScriptLoader.cpp:376:
contextDocument->addConsoleMessage(ConsoleMessage::create(SecurityMessageSource,
ErrorMessageLevel, "Cannot enforce integrity on non-CORS enabled resource."));
On 2015/02/26 08:44:52, Mike West wrote:
> So we continue loading the resource if the CORS check fails? This isn't what
we
> do for other CORS-related checks, like `<script crossorigin>`... was this an
> intentional decision? I'm willing to defer to the folks actually editing the
> spec, but I'd like to know it was a conscious decision.

You're right, I misread the algorithm (as you point out in a more detailed
comment later). I'm changing this to kill the resource.

https://codereview.chromium.org/954233003/diff/1/Source/core/fetch/CSSStyleSh...
File Source/core/fetch/CSSStyleSheetResource.h (right):

https://codereview.chromium.org/954233003/diff/1/Source/core/fetch/CSSStyleSh...
Source/core/fetch/CSSStyleSheetResource.h:55: bool isCORSNeededAndFailed() const
{ return m_corsNeededAndFailed; }
On 2015/02/26 08:44:52, Mike West wrote:
> "CORS needed" for what? CORS isn't needed to load the resource, it's only
needed
> for the SRI check, right? Can you rename this to something like
> "eligibleForIntegrityValidation"? It might be worth pushing that all the way
up
> to Resource, actually; that might simplify the script check.

Agreed and done (that is, moved to Resource).

https://codereview.chromium.org/954233003/diff/1/Source/core/fetch/ResourceFe...
File Source/core/fetch/ResourceFetcher.cpp (right):

https://codereview.chromium.org/954233003/diff/1/Source/core/fetch/ResourceFe...
Source/core/fetch/ResourceFetcher.cpp:605: bool
ResourceFetcher::canAccessResource(Resource* resource, SecurityOrigin*
sourceOrigin, const KURL& url, bool logErrors) const
On 2015/02/26 08:44:53, Mike West wrote:
> I'd prefer to replace this boolean with an enum so that it's clear at the
> callsites.

Done.

https://codereview.chromium.org/954233003/diff/1/Source/core/fetch/ResourceFe...
Source/core/fetch/ResourceFetcher.cpp:622:
toCSSStyleSheetResource(resource)->setCORSNeededAndFailed();
On 2015/02/26 08:44:53, Mike West wrote:
> It seems strange to set this as a side-effect of an access check. Perhaps you
> could structure this as a property of Resource (e.g. pass in a SecurityOrigin,
> and it tells you whether the algorithm in
>
https://w3c.github.io/webappsec/specs/subresourceintegrity/#is-resource-eligi...
> returns true.

Done.

https://codereview.chromium.org/954233003/diff/1/Source/core/fetch/ResourceLo...
File Source/core/fetch/ResourceLoader.cpp (right):

https://codereview.chromium.org/954233003/diff/1/Source/core/fetch/ResourceLo...
Source/core/fetch/ResourceLoader.cpp:365: if (m_resource->type() ==
Resource::CSSStyleSheet && !m_host->canAccessResource(m_resource,
m_options.securityOrigin.get(), response.url(), false))
On 2015/02/26 08:44:53, Mike West wrote:
> 1. I think we should only do this check if we actually need to (e.g. if an
> integrity attribute is present.
> 
> 2. You don't need to `setCORSNeededAndFailed`, as it's done as a side-effect
of
> failing the `canAccessResource` check, isn't it? (Note: this is an argument
for
> restructuring the code, as this kind of side-effect is tough to follow).

I think these are both addressed by the bigger refactor (and removal of the side
effect)

https://codereview.chromium.org/954233003/diff/1/Source/core/html/HTMLLinkEle...
File Source/core/html/HTMLLinkElement.cpp (right):

https://codereview.chromium.org/954233003/diff/1/Source/core/html/HTMLLinkEle...
Source/core/html/HTMLLinkElement.cpp:513:
document().addConsoleMessage(ConsoleMessage::create(SecurityMessageSource,
ErrorMessageLevel, "Cannot enforce integrity on non-CORS enabled resource."));
On 2015/02/26 08:44:53, Mike West wrote:
> Same question as I had with script: should we just allow the request? I don't
> think that's actually what the spec says (e.g.
>
https://w3c.github.io/webappsec/specs/subresourceintegrity/#is-resource-eligi...
> returns false, so
>
https://w3c.github.io/webappsec/specs/subresourceintegrity/#does-resource-mat...
> returns false in step 2.

Agreed as per my response in ScriptLoader.cpp. Fixed.

[Mike West, 2015-03-06 03:17:09]

Code looks significantly better, thanks!

I have some suggestions for tests, though. WDYT?

https://codereview.chromium.org/954233003/diff/40001/LayoutTests/http/tests/s...
File
LayoutTests/http/tests/security/subresourceIntegrity/subresource-integrity-script-cors.html
(right):

https://codereview.chromium.org/954233003/diff/40001/LayoutTests/http/tests/s...
LayoutTests/http/tests/security/subresourceIntegrity/subresource-integrity-script-cors.html:17:
description("The test passes if the script loads without any console error
messages.");
Instead of this style, would you mind rewriting this and the other new tests to
use `testharness.js`? Then you can simply assert that the value is set
correctly, and can drop the '-expectations.txt' file.

https://codereview.chromium.org/954233003/diff/40001/LayoutTests/http/tests/s...
File
LayoutTests/http/tests/security/subresourceIntegrity/subresource-integrity-script-no-cors.html
(right):

https://codereview.chromium.org/954233003/diff/40001/LayoutTests/http/tests/s...
LayoutTests/http/tests/security/subresourceIntegrity/subresource-integrity-script-no-cors.html:19:
<script integrity="ni:///sha256;deadbeef"
src="http://localhost:8000/security/resources/cors-script.php?credentials=true&cors=false&value=true"
onload="scriptLoaded();"></script>
You're conflating a few things here: 

1. You've dropped the `crossorigin` attribute.
2. You've broken the `integrity` attribute.
3. You've dropped the ACAO header.

Any of these might be causing the failure. Would you mind splitting these out
into separate tests so that we have a good idea of the expected behavior for
each?

https://codereview.chromium.org/954233003/diff/40001/LayoutTests/http/tests/s...
File
LayoutTests/http/tests/security/subresourceIntegrity/subresource-integrity-style-no-cors.html
(right):

https://codereview.chromium.org/954233003/diff/40001/LayoutTests/http/tests/s...
LayoutTests/http/tests/security/subresourceIntegrity/subresource-integrity-style-no-cors.html:5:
integrity="ni:///sha256;deadbeef"
Ditto the script comments.

[Mike West, 2015-03-06 03:19:37]

https://codereview.chromium.org/954233003/diff/40001/Source/core/frame/Subres...
File Source/core/frame/SubresourceIntegrityTest.cpp (right):

https://codereview.chromium.org/954233003/diff/40001/Source/core/frame/Subres...
Source/core/frame/SubresourceIntegrityTest.cpp:158:
response->setHTTPHeaderField("access-control-allow-origin",
SecurityOrigin::create(allowOriginUrl)->toAtomicString());
It would be nice if this bit was parameterized; right now you're testing that
CORS headers allow a resource to be integrity-checked cross-origin, but you're
not yet verifying that lacking CORS headers blocks integrity checking.

[jww, 2015-03-06 08:24:22]

https://codereview.chromium.org/954233003/diff/40001/LayoutTests/http/tests/s...
File
LayoutTests/http/tests/security/subresourceIntegrity/subresource-integrity-script-cors.html
(right):

https://codereview.chromium.org/954233003/diff/40001/LayoutTests/http/tests/s...
LayoutTests/http/tests/security/subresourceIntegrity/subresource-integrity-script-cors.html:17:
description("The test passes if the script loads without any console error
messages.");
On 2015/03/06 03:17:09, Mike West wrote:
> Instead of this style, would you mind rewriting this and the other new tests
to
> use `testharness.js`? Then you can simply assert that the value is set
> correctly, and can drop the '-expectations.txt' file.

That works in this case, but in the other tests we're partially testing the
console error messages that appear. Is there any way to test that with
testharness.js?

https://codereview.chromium.org/954233003/diff/40001/LayoutTests/http/tests/s...
File
LayoutTests/http/tests/security/subresourceIntegrity/subresource-integrity-script-no-cors.html
(right):

https://codereview.chromium.org/954233003/diff/40001/LayoutTests/http/tests/s...
LayoutTests/http/tests/security/subresourceIntegrity/subresource-integrity-script-no-cors.html:19:
<script integrity="ni:///sha256;deadbeef"
src="http://localhost:8000/security/resources/cors-script.php?credentials=true&cors=false&value=true"
onload="scriptLoaded();"></script>
On 2015/03/06 03:17:09, Mike West wrote:
> You're conflating a few things here: 
> 
> 1. You've dropped the `crossorigin` attribute.
> 2. You've broken the `integrity` attribute.
> 3. You've dropped the ACAO header.
> 
> Any of these might be causing the failure. Would you mind splitting these out
> into separate tests so that we have a good idea of the expected behavior for
> each?

Yup, I added a bunch of tests. This is probably as good a place as any to
mention that these tests demonstrate a slight difference from the spec in our
implementation. Namely, when an integrity causes a resource load failure, the
load event still fires, rather than the error event. However, as discussed in
https://github.com/w3c/webappsec/issues/149, this is still a bit up in the air,
so I'm not going to change it (yet). I did file https://crbug.com/464648 to
track this, however.

https://codereview.chromium.org/954233003/diff/40001/LayoutTests/http/tests/s...
File
LayoutTests/http/tests/security/subresourceIntegrity/subresource-integrity-style-no-cors.html
(right):

https://codereview.chromium.org/954233003/diff/40001/LayoutTests/http/tests/s...
LayoutTests/http/tests/security/subresourceIntegrity/subresource-integrity-style-no-cors.html:5:
integrity="ni:///sha256;deadbeef"
On 2015/03/06 03:17:09, Mike West wrote:
> Ditto the script comments.

See reply to your scripts comments.

https://codereview.chromium.org/954233003/diff/40001/Source/core/frame/Subres...
File Source/core/frame/SubresourceIntegrityTest.cpp (right):

https://codereview.chromium.org/954233003/diff/40001/Source/core/frame/Subres...
Source/core/frame/SubresourceIntegrityTest.cpp:158:
response->setHTTPHeaderField("access-control-allow-origin",
SecurityOrigin::create(allowOriginUrl)->toAtomicString());
On 2015/03/06 03:19:37, Mike West wrote:
> It would be nice if this bit was parameterized; right now you're testing that
> CORS headers allow a resource to be integrity-checked cross-origin, but you're
> not yet verifying that lacking CORS headers blocks integrity checking.

Done.

[Mike West, 2015-03-06 09:07:52]

LGTM % testharness.js. I really would like to see the interoperable bits tested
in an interoperable way. See below for more on that topic:

https://codereview.chromium.org/954233003/diff/40001/LayoutTests/http/tests/s...
File
LayoutTests/http/tests/security/subresourceIntegrity/subresource-integrity-script-cors.html
(right):

https://codereview.chromium.org/954233003/diff/40001/LayoutTests/http/tests/s...
LayoutTests/http/tests/security/subresourceIntegrity/subresource-integrity-script-cors.html:17:
description("The test passes if the script loads without any console error
messages.");
On 2015/03/06 at 08:24:21, jww wrote:
> On 2015/03/06 03:17:09, Mike West wrote:
> > Instead of this style, would you mind rewriting this and the other new tests
to
> > use `testharness.js`? Then you can simply assert that the value is set
> > correctly, and can drop the '-expectations.txt' file.
> 
> That works in this case, but in the other tests we're partially testing the
console error messages that appear. Is there any way to test that with
testharness.js?

If you want to test the error message, then yes, you need a test with an
-expectation file. We intentionally don't expose the console message's content
to JavaScript, as it's sensitive (hashes === content).

Those should be written _in addition_ to the testharness.js tests, as the
testharness.js tests can be submitted to the W3C, but the console message tests
can't. That is, the _interoperable_ parts of the feature (does the thing load?)
should be tested in an interoperable way. The Blink-specific bits (console
messages) can be tested however you like. :)

I'd love to see you rewrite these tests under testharness, and submit them to
https://github.com/w3c/web-platform-tests/ to get started on a real test suite
for the feature. We can get the Mozilla folks to help out, as these tests should
work for everyone.

[jww, 2015-03-06 22:14:11]

On 2015/03/06 09:07:52, Mike West wrote:
> LGTM % testharness.js. I really would like to see the interoperable bits
tested
> in an interoperable way. See below for more on that topic:
> 
>
https://codereview.chromium.org/954233003/diff/40001/LayoutTests/http/tests/s...
> File
>
LayoutTests/http/tests/security/subresourceIntegrity/subresource-integrity-script-cors.html
> (right):
> 
>
https://codereview.chromium.org/954233003/diff/40001/LayoutTests/http/tests/s...
>
LayoutTests/http/tests/security/subresourceIntegrity/subresource-integrity-script-cors.html:17:
> description("The test passes if the script loads without any console error
> messages.");
> On 2015/03/06 at 08:24:21, jww wrote:
> > On 2015/03/06 03:17:09, Mike West wrote:
> > > Instead of this style, would you mind rewriting this and the other new
tests
> to
> > > use `testharness.js`? Then you can simply assert that the value is set
> > > correctly, and can drop the '-expectations.txt' file.
> > 
> > That works in this case, but in the other tests we're partially testing the
> console error messages that appear. Is there any way to test that with
> testharness.js?
> 
> If you want to test the error message, then yes, you need a test with an
> -expectation file. We intentionally don't expose the console message's content
> to JavaScript, as it's sensitive (hashes === content).
> 
> Those should be written _in addition_ to the testharness.js tests, as the
> testharness.js tests can be submitted to the W3C, but the console message
tests
> can't. That is, the _interoperable_ parts of the feature (does the thing
load?)
> should be tested in an interoperable way. The Blink-specific bits (console
> messages) can be tested however you like. :)
> 
> I'd love to see you rewrite these tests under testharness, and submit them to
> https://github.com/w3c/web-platform-tests/ to get started on a real test suite
> for the feature. We can get the Mozilla folks to help out, as these tests
should
> work for everyone.

Sorry for the delay on this CL. I've actually got everything "working" as per
your suggestions, but I've run into a weird bug that I'll have to fix first.
Hopefully you'll see a CL for that shortly :-)

[jww, 2015-03-06 23:49:47]

On 2015/03/06 22:14:11, jww wrote:
> On 2015/03/06 09:07:52, Mike West wrote:
> > LGTM % testharness.js. I really would like to see the interoperable bits
> tested
> > in an interoperable way. See below for more on that topic:
> > 
> >
>
https://codereview.chromium.org/954233003/diff/40001/LayoutTests/http/tests/s...
> > File
> >
>
LayoutTests/http/tests/security/subresourceIntegrity/subresource-integrity-script-cors.html
> > (right):
> > 
> >
>
https://codereview.chromium.org/954233003/diff/40001/LayoutTests/http/tests/s...
> >
>
LayoutTests/http/tests/security/subresourceIntegrity/subresource-integrity-script-cors.html:17:
> > description("The test passes if the script loads without any console error
> > messages.");
> > On 2015/03/06 at 08:24:21, jww wrote:
> > > On 2015/03/06 03:17:09, Mike West wrote:
> > > > Instead of this style, would you mind rewriting this and the other new
> tests
> > to
> > > > use `testharness.js`? Then you can simply assert that the value is set
> > > > correctly, and can drop the '-expectations.txt' file.
> > > 
> > > That works in this case, but in the other tests we're partially testing
the
> > console error messages that appear. Is there any way to test that with
> > testharness.js?
> > 
> > If you want to test the error message, then yes, you need a test with an
> > -expectation file. We intentionally don't expose the console message's
content
> > to JavaScript, as it's sensitive (hashes === content).
> > 
> > Those should be written _in addition_ to the testharness.js tests, as the
> > testharness.js tests can be submitted to the W3C, but the console message
> tests
> > can't. That is, the _interoperable_ parts of the feature (does the thing
> load?)
> > should be tested in an interoperable way. The Blink-specific bits (console
> > messages) can be tested however you like. :)
> > 
> > I'd love to see you rewrite these tests under testharness, and submit them
to
> > https://github.com/w3c/web-platform-tests/ to get started on a real test
suite
> > for the feature. We can get the Mozilla folks to help out, as these tests
> should
> > work for everyone.
> 
> Sorry for the delay on this CL. I've actually got everything "working" as per
> your suggestions, but I've run into a weird bug that I'll have to fix first.
> Hopefully you'll see a CL for that shortly :-)

Okay, I've got a CL up (https://codereview.chromium.org/984213002/) that fixes
the blocking issue. Once that's committed, I'll get back to finishing this one.

[jww, 2015-03-09 22:07:45]

Moved all the tests onto testharness. Just waiting for
https://codereview.chromium.org/986393003 to land so that this passes the
presubmit.

https://codereview.chromium.org/954233003/diff/40001/LayoutTests/http/tests/s...
File
LayoutTests/http/tests/security/subresourceIntegrity/subresource-integrity-script-cors.html
(right):

https://codereview.chromium.org/954233003/diff/40001/LayoutTests/http/tests/s...
LayoutTests/http/tests/security/subresourceIntegrity/subresource-integrity-script-cors.html:17:
description("The test passes if the script loads without any console error
messages.");
On 2015/03/06 09:07:52, Mike West wrote:
> On 2015/03/06 at 08:24:21, jww wrote:
> > On 2015/03/06 03:17:09, Mike West wrote:
> > > Instead of this style, would you mind rewriting this and the other new
tests
> to
> > > use `testharness.js`? Then you can simply assert that the value is set
> > > correctly, and can drop the '-expectations.txt' file.
> > 
> > That works in this case, but in the other tests we're partially testing the
> console error messages that appear. Is there any way to test that with
> testharness.js?
> 
> If you want to test the error message, then yes, you need a test with an
> -expectation file. We intentionally don't expose the console message's content
> to JavaScript, as it's sensitive (hashes === content).
Yeah, I was hoping there was some test-mode-only API for grabbing console
messages, but your comment below clarifies why not.
> 
> Those should be written _in addition_ to the testharness.js tests, as the
> testharness.js tests can be submitted to the W3C, but the console message
tests
> can't. That is, the _interoperable_ parts of the feature (does the thing
load?)
> should be tested in an interoperable way. The Blink-specific bits (console
> messages) can be tested however you like. :)
> 
> I'd love to see you rewrite these tests under testharness, and submit them to
> https://github.com/w3c/web-platform-tests/ to get started on a real test suite
> for the feature. We can get the Mozilla folks to help out, as these tests
should
> work for everyone.

Sounds great. I'll rewrite with testharness.js, but as I mentioned in the
earlier comment, given that the load event/error event part of the spec is still
being decided, I'm going to hold off on submitting these tests until that's
settled (since they're dependent on the load/error events).

[jww, 2015-03-10 23:23:14]

The CQ bit was checked by jww@chromium.org

[jww, 2015-03-10 23:23:15]

The patchset sent to the CQ was uploaded after l-g-t-m from mkwst@chromium.org
Link to the patchset: https://codereview.chromium.org/954233003/#ps100001
(title: "Rebase on ToT")

[commit-bot: I haz the power, 2015-03-10 23:23:45]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/954233003/100001

[commit-bot: I haz the power, 2015-03-11 02:24:09]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-03-11 02:24:10]

Try jobs failed on following builders:
  win_blink_rel on tryserver.blink (JOB_FAILED,
http://build.chromium.org/p/tryserver.blink/builders/win_blink_rel/builds/54378)

[jww, 2015-03-11 04:22:30]

The CQ bit was checked by jww@chromium.org

[jww, 2015-03-11 04:22:30]

The patchset sent to the CQ was uploaded after l-g-t-m from mkwst@chromium.org
Link to the patchset: https://codereview.chromium.org/954233003/#ps120001
(title: "Fixed test failures")

[commit-bot: I haz the power, 2015-03-11 04:22:48]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/954233003/120001

[commit-bot: I haz the power, 2015-03-11 05:48:35]

Committed patchset #7 (id:120001) as
https://src.chromium.org/viewvc/blink?view=rev&revision=191682

[jww, 2015-03-11 17:38:32]

A revert of this CL (patchset #7 id:120001) has been created in
https://codereview.chromium.org/997083003/ by jww@chromium.org.

The reason for reverting is: Blink memory leak..