CSP: Fire 'SecurityPolicyViolation' on the offending element.

CSP: Fire 'SecurityPolicyViolation' on the offending element.

If we can identify a specific element for a CSP violation (e.g. in the
cases of inline script, style, or event handlers), then target those
elements when firing a 'SecurityPolicyViolation' event.

We'll also need to ensure that the event bubbles so that we don't break
existing collection endpoints that listen on 'Document'.

Committed: https://crrev.com/357d8e12ff388c450cdc431a3e5865737d84d2e2
Cr-Commit-Position: refs/heads/master@{#425937}

[Mike West, 2016-10-13 15:21:25]

The CQ bit was checked by mkwst@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-13 15:21:51]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Mike West, 2016-10-13 15:23:07]

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

[Mike West, 2016-10-13 15:23:08]

Philip: Since you know things about events, could you take a look at the small
change to `ContentSecurityPolicy::reportViolation()` to tell me if I need to be
firing events on the element in some other way in order to account for the
things you mentioned on Twitter? :)

I'll find someone else to review the guts of the patch once I write some tests.

[foolip, 2016-10-13 15:37:27]

https://codereview.chromium.org/2421473004/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/frame/csp/ContentSecurityPolicy.cpp (right):

https://codereview.chromium.org/2421473004/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/frame/csp/ContentSecurityPolicy.cpp:1208: if
(element) {
Is it possible that this element isn't connected?

Maybe `[Exposed=Window] readonly attribute Element? element` on
SecurityPolicyViolationEvent would work, But then the interaction with Shadow
DOM wouldn't be fun. event.element would have to be the shadow host, and there
would be no way to figure out the real source inside the shadow tree.

Does it matter if not every violation is caught by
document.addEventListener('securitypolicyviolation', ...)? What currently
happens if you move an element to another document with unlucky timing?

[commit-bot: I haz the power, 2016-10-13 15:37:32]

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

[commit-bot: I haz the power, 2016-10-13 15:37:34]

Dry run: Try jobs failed on following builders:
  linux_chromium_compile_dbg_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Mike West, 2016-10-13 19:00:52]

On 2016/10/13 at 15:37:27, foolip wrote:
>
https://codereview.chromium.org/2421473004/diff/20001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/core/frame/csp/ContentSecurityPolicy.cpp
(right):
> 
>
https://codereview.chromium.org/2421473004/diff/20001/third_party/WebKit/Sour...
> third_party/WebKit/Source/core/frame/csp/ContentSecurityPolicy.cpp:1208: if
(element) {
> Is it possible that this element isn't connected?

I don't think so, given the way the processing works: we're only hitting this
path with an |element| for an inline violation. That is, either we're about to
execute `<script>whatever</script>`, parse `<style>whatever</style>`, or we're
about to fire an inline event handler. Off the top of my head, I'd say you have
to be connected to be parsed for execution.

I suppose I could DCHECK that.
 
> Maybe `[Exposed=Window] readonly attribute Element? element` on
SecurityPolicyViolationEvent would work, But then the interaction with Shadow
DOM wouldn't be fun. event.element would have to be the shadow host, and there
would be no way to figure out the real source inside the shadow tree.

That seems strange.

> Does it matter if not every violation is caught by
document.addEventListener('securitypolicyviolation', ...)? What currently
happens if you move an element to another document with unlucky timing?

I'm ~90% sure this isn't possible, given the above restrictions.  I don't think
there's a point at which JavaScript can interpose on the element between parsing
and violation, but the web is weird. Let's assume it's possible.

We currently fire against the policy's `Document`, not the |element|, for all
violations. I'd like to ensure that every violation event has the opportunity to
reach `Document`. If it gets cancelled inbetween, no worries.

[Mike West, 2016-10-14 08:26:31]

The CQ bit was checked by mkwst@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-14 08:26:41]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Mike West, 2016-10-14 08:28:37]

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

[Mike West, 2016-10-14 08:28:37]

I got some good feedback from Anne at
https://github.com/w3c/webappsec-csp/issues/128. The latest version of the patch
addresses that feedback, and adds a few tests for the various cases where we can
fire events at specific elements.

foolip@: Would you mind taking a closer look at the event changes for sanity?

jochen@: Would you take a look at the changes to the CSP interface (and the
resulting trivial changes to the API's callsites)?

[commit-bot: I haz the power, 2016-10-14 08:29:12]

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

[commit-bot: I haz the power, 2016-10-14 08:29:12]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Mike West, 2016-10-14 08:34:53]

The CQ bit was checked by mkwst@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-14 08:35:06]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[foolip, 2016-10-14 09:17:23]

https://codereview.chromium.org/2421473004/diff/60001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/securitypolicyviolation/targeting.html
(right):

https://codereview.chromium.org/2421473004/diff/60001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/securitypolicyviolation/targeting.html:1:
<!doctype html>
Whatever the spec'd behavior, some test where the inline element is removed is
needed, as well as one where it's moved to another Document and maybe one for
DocumentFragment.

https://codereview.chromium.org/2421473004/diff/60001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/securitypolicyviolation/targeting.html:7:
var watcher = new EventWatcher(t, document, ['securitypolicyviolation',
'securitypolicyviolation', 'securitypolicyviolation', 'securitypolicyviolation',
'securitypolicyviolation']);
This doesn't seem right, in testharness.js this will call addEventListener 5
times, but the last 4 are no-ops. It looks like wait_for is the one that takes
an array of things to wait for. If the test still passes, then I don't
understand how this works :)

https://codereview.chromium.org/2421473004/diff/60001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/securitypolicyviolation/targeting.html:55:
var shadow = document.querySelector('#block4').createShadowRoot();
createShadowRoot() -> attachShadow() (yes, createShadowRoot() in Element.idl
should be marked as non-standard)

I'd also suggest doing as much of the setup as possible inside a test, so that
exceptions fail the right test.

https://codereview.chromium.org/2421473004/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/frame/csp/CSPDirectiveList.cpp (right):

https://codereview.chromium.org/2421473004/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/frame/csp/CSPDirectiveList.cpp:535:
!toHTMLScriptElement(element)->loader()->isParserInserted() &&
Off-topic: Confirmed that loader() can't be null, so I guess it could be made to
return a reference now.

https://codereview.chromium.org/2421473004/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/frame/csp/ContentSecurityPolicy.cpp (right):

https://codereview.chromium.org/2421473004/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/frame/csp/ContentSecurityPolicy.cpp:1208: if
(element) {
Commented in
https://github.com/w3c/webappsec-csp/issues/128#issuecomment-253746277, I think
probably `element && element->isConnected()` here.

BTW, it's not super clear to me when element would be null here, some
documentation here and in places where Element* is an argument would be nice.

https://codereview.chromium.org/2421473004/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/frame/csp/ContentSecurityPolicy.cpp:1211:
frame->localDOMWindow()->enqueueDocumentEvent(event);
This queues a task (or uses an in-flight task) to dispatch the event, the above
dispatches synchronously. The timing really should be the same. It was
previously posting a task, but can we ever reach this code with scripts on the
stack? If this is a reaction to something that happens in the network stack or
anything async then firing synchronously here is probably the right thing. Is
the precise timing nailed down in the spec?

[jochen (gone - plz use gerrit), 2016-10-14 09:18:32]

lgtm

[commit-bot: I haz the power, 2016-10-14 10:02:23]

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

[commit-bot: I haz the power, 2016-10-14 10:02:24]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[Mike West, 2016-10-14 12:26:18]

The CQ bit was checked by mkwst@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-14 12:26:37]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Mike West, 2016-10-14 12:26:43]

Thanks to you both!

https://codereview.chromium.org/2421473004/diff/60001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/securitypolicyviolation/targeting.html
(right):

https://codereview.chromium.org/2421473004/diff/60001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/securitypolicyviolation/targeting.html:1:
<!doctype html>
On 2016/10/14 at 09:17:23, foolip wrote:
> Whatever the spec'd behavior, some test where the inline element is removed is
needed, as well as one where it's moved to another Document and maybe one for
DocumentFragment.

Added.

https://codereview.chromium.org/2421473004/diff/60001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/securitypolicyviolation/targeting.html:7:
var watcher = new EventWatcher(t, document, ['securitypolicyviolation',
'securitypolicyviolation', 'securitypolicyviolation', 'securitypolicyviolation',
'securitypolicyviolation']);
On 2016/10/14 at 09:17:23, foolip wrote:
> This doesn't seem right, in testharness.js this will call addEventListener 5
times, but the last 4 are no-ops. It looks like wait_for is the one that takes
an array of things to wait for. If the test still passes, then I don't
understand how this works :)

Looks like I misunderstood the mechanism.

https://codereview.chromium.org/2421473004/diff/60001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/securitypolicyviolation/targeting.html:55:
var shadow = document.querySelector('#block4').createShadowRoot();
On 2016/10/14 at 09:17:23, foolip wrote:
> createShadowRoot() -> attachShadow() (yes, createShadowRoot() in Element.idl
should be marked as non-standard)
> 
> I'd also suggest doing as much of the setup as possible inside a test, so that
exceptions fail the right test.

Done and done.

https://codereview.chromium.org/2421473004/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/frame/csp/CSPDirectiveList.cpp (right):

https://codereview.chromium.org/2421473004/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/frame/csp/CSPDirectiveList.cpp:535:
!toHTMLScriptElement(element)->loader()->isParserInserted() &&
On 2016/10/14 at 09:17:23, foolip wrote:
> Off-topic: Confirmed that loader() can't be null, so I guess it could be made
to return a reference now.

SGTM!

https://codereview.chromium.org/2421473004/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/frame/csp/ContentSecurityPolicy.cpp (right):

https://codereview.chromium.org/2421473004/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/frame/csp/ContentSecurityPolicy.cpp:1208: if
(element) {
On 2016/10/14 at 09:17:23, foolip wrote:
> Commented in
https://github.com/w3c/webappsec-csp/issues/128#issuecomment-253746277, I think
probably `element && element->isConnected()` here.
> 
> BTW, it's not super clear to me when element would be null here, some
documentation here and in places where Element* is an argument would be nice.

|element| is null in every case where a network request caused the violation (as
we don't have any mechanism to wire up a request to its initiator element from
inside the Fetch machinery).

|element| can also be null for inline violations where we don't have an element
to tie things to. Like, navigation to a `javascript:` URL is an inline
violation, and in theory we could pass things through the whole navigation
chain, but we don't today.

https://codereview.chromium.org/2421473004/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/frame/csp/ContentSecurityPolicy.cpp:1211:
frame->localDOMWindow()->enqueueDocumentEvent(event);
On 2016/10/14 at 09:17:23, foolip wrote:
> This queues a task (or uses an in-flight task) to dispatch the event, the
above dispatches synchronously. The timing really should be the same. It was
previously posting a task, but can we ever reach this code with scripts on the
stack? If this is a reaction to something that happens in the network stack or
anything async then firing synchronously here is probably the right thing.

Changed to synchronousness.

> Is the precise timing nailed down in the spec?

https://w3c.github.io/webappsec-csp/#report-violation and its various callsites
execute either during Fetch, or during parsing.

[foolip, 2016-10-14 12:51:22]

https://codereview.chromium.org/2421473004/diff/80001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/securitypolicyviolation/targeting.html
(right):

https://codereview.chromium.org/2421473004/diff/80001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/securitypolicyviolation/targeting.html:6:
async_test(t => {
Optional nit: promise_test might get rid of a lot of t.step_func wrapping.

https://codereview.chromium.org/2421473004/diff/80001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/securitypolicyviolation/targeting.html:98:
d.addEventListener('securitypolicyviolation', t.step_func(e => {
If this event isn't fired, should the test fail?

https://codereview.chromium.org/2421473004/diff/80001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/securitypolicyviolation/targeting.html:107:
d.click();
I'm thinking it should first be inserted into this document, then click or
whatever causes an event-firing task to be queued, then move to another document
before that task runs.

And something similar for merely removing.

[foolip, 2016-10-14 13:00:24]

On 2016/10/14 12:26:43, Mike West wrote:

> > Is the precise timing nailed down in the spec?
> 
> https://w3c.github.io/webappsec-csp/#report-violation and its various
callsites
> execute either during Fetch, or during parsing.

Ah, so given that "Report a violation" is sometimes invoked from the parser or
maybe while events are being dispatched, it should probably have this structure:

1. Let global be violation’s global object.
2. Let target be violation’s element.
3. Queue a task to run the remaining steps.

And things can change before that task is run, which is why the tests will be
hilarious :)

[Mike West, 2016-10-14 13:16:19]

The CQ bit was checked by mkwst@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-14 13:16:39]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-14 13:37:48]

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

[commit-bot: I haz the power, 2016-10-14 13:37:50]

Dry run: Try jobs failed on following builders:
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)

[Mike West, 2016-10-14 15:47:05]

The CQ bit was checked by mkwst@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-14 15:47:56]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-14 16:29:02]

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

[commit-bot: I haz the power, 2016-10-14 16:29:03]

Dry run: Try jobs failed on following builders:
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)

[Mike West, 2016-10-17 07:44:57]

The CQ bit was checked by mkwst@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-17 07:45:19]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-17 08:20:45]

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

[commit-bot: I haz the power, 2016-10-17 08:20:46]

Dry run: Exceeded global retry quota

[Mike West, 2016-10-17 11:42:29]

The CQ bit was checked by mkwst@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-17 11:42:41]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Mike West, 2016-10-17 11:44:41]

foolip@: Since you like boring details, help me with this boring detail. :P

https://codereview.chromium.org/2421473004/diff/80001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/securitypolicyviolation/targeting.html
(right):

https://codereview.chromium.org/2421473004/diff/80001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/securitypolicyviolation/targeting.html:98:
d.addEventListener('securitypolicyviolation', t.step_func(e => {
On 2016/10/14 at 12:51:21, foolip wrote:
> If this event isn't fired, should the test fail?

Yup. Added a counter.

https://codereview.chromium.org/2421473004/diff/160001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/nonces/script-enforce-blocked.php
(right):

https://codereview.chromium.org/2421473004/diff/160001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/nonces/script-enforce-blocked.php:15:
49: true,
Before I spend too much time banging my head against this test, halp!

The URL-based events are firing. The inline events are not. (e.g. the
console.log on line 33 fires 4 times). `printf` shows me that I'm sending 9
events to the page. Is there some parse-time weirdness that would cause some of
the inline scripts to be "connected" to the current document, but events fired
upon them not to bubble up to the document? I'm confused. :(

[foolip, 2016-10-17 12:04:28]

https://codereview.chromium.org/2421473004/diff/160001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/nonces/script-enforce-blocked.php
(right):

https://codereview.chromium.org/2421473004/diff/160001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/nonces/script-enforce-blocked.php:15:
49: true,
On 2016/10/17 11:44:40, Mike West wrote:
> Before I spend too much time banging my head against this test, halp!
> 
> The URL-based events are firing. The inline events are not. (e.g. the
> console.log on line 33 fires 4 times). `printf` shows me that I'm sending 9
> events to the page. Is there some parse-time weirdness that would cause some
of
> the inline scripts to be "connected" to the current document, but events fired
> upon them not to bubble up to the document? I'm confused. :(

As discussed on chat, maybe the event doesn't bubble.

[Mike West, 2016-10-17 12:23:37]

The CQ bit was checked by mkwst@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-17 12:23:51]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Mike West, 2016-10-17 12:24:02]

On 2016/10/17 at 12:04:28, foolip wrote:
>
https://codereview.chromium.org/2421473004/diff/160001/third_party/WebKit/Lay...
> File
third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/nonces/script-enforce-blocked.php
(right):
> 
>
https://codereview.chromium.org/2421473004/diff/160001/third_party/WebKit/Lay...
>
third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/nonces/script-enforce-blocked.php:15:
49: true,
> On 2016/10/17 11:44:40, Mike West wrote:
> > Before I spend too much time banging my head against this test, halp!
> > 
> > The URL-based events are firing. The inline events are not. (e.g. the
> > console.log on line 33 fires 4 times). `printf` shows me that I'm sending 9
> > events to the page. Is there some parse-time weirdness that would cause some
of
> > the inline scripts to be "connected" to the current document, but events
fired
> > upon them not to bubble up to the document? I'm confused. :(
> 
> As discussed on chat, maybe the event doesn't bubble.

Yes. Me is dumb.

I think the latest patchset actually works. WDYT?

[foolip, 2016-10-17 12:27:22]

On 2016/10/17 12:24:02, Mike West wrote:
> On 2016/10/17 at 12:04:28, foolip wrote:
> >
>
https://codereview.chromium.org/2421473004/diff/160001/third_party/WebKit/Lay...
> > File
>
third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/nonces/script-enforce-blocked.php
> (right):
> > 
> >
>
https://codereview.chromium.org/2421473004/diff/160001/third_party/WebKit/Lay...
> >
>
third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/nonces/script-enforce-blocked.php:15:
> 49: true,
> > On 2016/10/17 11:44:40, Mike West wrote:
> > > Before I spend too much time banging my head against this test, halp!
> > > 
> > > The URL-based events are firing. The inline events are not. (e.g. the
> > > console.log on line 33 fires 4 times). `printf` shows me that I'm sending
9
> > > events to the page. Is there some parse-time weirdness that would cause
some
> of
> > > the inline scripts to be "connected" to the current document, but events
> fired
> > > upon them not to bubble up to the document? I'm confused. :(
> > 
> > As discussed on chat, maybe the event doesn't bubble.
> 
> Yes. Me is dumb.
> 
> I think the latest patchset actually works. WDYT?

Me thinks LGTM.

[commit-bot: I haz the power, 2016-10-17 13:25:10]

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

[commit-bot: I haz the power, 2016-10-17 13:25:11]

Dry run: Try jobs failed on following builders:
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Mike West, 2016-10-18 08:38:51]

The CQ bit was checked by mkwst@chromium.org

[Mike West, 2016-10-18 08:38:52]

The patchset sent to the CQ was uploaded after l-g-t-m from jochen@chromium.org,
foolip@chromium.org
Link to the patchset: https://codereview.chromium.org/2421473004/#ps200001
(title: "Test.")

[commit-bot: I haz the power, 2016-10-18 08:39:12]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-18 10:02:51]

Committed patchset #11 (id:200001)

[commit-bot: I haz the power, 2016-10-18 10:05:14]

Description was changed from

==========
CSP: Fire 'SecurityPolicyViolation' on the offending element.

If we can identify a specific element for a CSP violation (e.g. in the
cases of inline script, style, or event handlers), then target those
elements when firing a 'SecurityPolicyViolation' event.

We'll also need to ensure that the event bubbles so that we don't break
existing collection endpoints that listen on 'Document'.
==========

to

==========
CSP: Fire 'SecurityPolicyViolation' on the offending element.

If we can identify a specific element for a CSP violation (e.g. in the
cases of inline script, style, or event handlers), then target those
elements when firing a 'SecurityPolicyViolation' event.

We'll also need to ensure that the event bubbles so that we don't break
existing collection endpoints that listen on 'Document'.

Committed: https://crrev.com/357d8e12ff388c450cdc431a3e5865737d84d2e2
Cr-Commit-Position: refs/heads/master@{#425937}
==========

[commit-bot: I haz the power, 2016-10-18 10:05:15]

Patchset 11 (id:??) landed as
https://crrev.com/357d8e12ff388c450cdc431a3e5865737d84d2e2
Cr-Commit-Position: refs/heads/master@{#425937}