Should securitypolicyviolation have element set in more cases

[annevk]

Currently only https://w3c.github.io/webappsec-csp/#should-block-inline sets it, but it seems for a large set of Fetch cases it could also be set, provided we refactor Fetch and HTML...

Per @mikewest that might also be what Chrome does.

[andypaicu]

We actually have tried recently to address this in Chrome but in turned out to be difficult for Chrome specific reasons. In principle I agree we should be able to set the element for a larger set of cases.

[annevk]

So Chrome doesn't set the element if e.g. a fetch triggered from <img> fails the check? @mikewest suggested to me that it did.

As I said in OP it's also difficult from a standards perspective, as that <img> element is "gone" by the time we do the CSP check, but not entirely unaddressable if we wanted to do this. If Chrome doesn't do this however, writing tests to ensure it doesn't get implemented might be sufficient for now.

[andypaicu]

It does not unfortunately, there is a bug for this crbug.com/737647.

I think I would rather we fix the standards (and the implementation), I don't think it makes sense to hide useful information from the developer if we can help it.

[annevk]

Okay, it would require rather extensive plumbing to make this work, with changes to both Fetch and HTML, but if you're up for that, including make sure it's all tested I don't really have any objections.