-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define securitypolicyviolation event #568
Conversation
Note: rebasing on main should fix the failing check. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. This LGTM, let's wait for whatwg/html#8351 for merging.
Following discussions in whatwg/html#8340, the events index in the HTML spec will be restricted to event types that gets fired within the HTML spec. The `securitypolicyviolation` event will be dropped from the index as a result. This turns the mention of `securitypolicyviolation` into a proper event type definition so that other specs (including the HTML spec to map `onsecuritypolicyviolation` to `securitypolicyviolation`) can reference it. This also defines the event targets more precisely. In HTML, the event was defined as firing on `HTMLElement`. In practice, if I read the spec correcty, the event fires on interfaces that derive from `GlobalEventHandlers` in general (`HTMLElement`, `MathMLElement`, `SVGElement`, `Document`), and on `WorkerGlobalScope`. I note that the definition of `WorkerGlobalScope` should probably also be amended in HTML to add an `onsecuritypolicyviolation` IDL attribute, as was done for `GlobalEventHandlers`. The definition of "policy" suggests that the event could in theory also fire on `WorkletGlobalScope` but that interface does not inherit from `EventTarget`. That seems to be adequately covered by the "Report a violation" algorithm. If firing at `WorkletGlobalScope` is also expected, more changes would be needed.
7c7a894
to
18c0935
Compare
I just rebased the pull request. That fixes the CI failure.
Actually, this PR should get merged before the one in HTML because the PR in HTML references the definition that this PR creates. |
Makes sense, let's just wait for it to be ready then! |
For sake of clarity, I'll mark the HTML ready once this PR is merged (and its sister DOM PR) - in other words, this PR should not be seen as having dependency on anything happening in HTML at this stage. |
Thanks for clarifying. I hadn't look in detail, the PR on html was marked as draft, so I assumed work just started there. Looking closer, it looks that PR is basically done, so fine with merging this. |
Following discussions in whatwg/html#8340, the events index in the HTML spec will be restricted to event types that gets fired within the HTML spec. The
securitypolicyviolation
event will be dropped from the index as a result.This turns the mention of
securitypolicyviolation
into a proper event type definition so that other specs (including the HTML spec to maponsecuritypolicyviolation
tosecuritypolicyviolation
) can reference it.This also defines the event targets more precisely. In HTML, the event was defined as firing on
HTMLElement
. In practice, if I read the spec correcty, the event fires on interfaces that derive fromGlobalEventHandlers
in general (HTMLElement
,MathMLElement
,SVGElement
,Document
), and onWorkerGlobalScope
.I note that the definition of
WorkerGlobalScope
should probably also be amended in HTML to add anonsecuritypolicyviolation
IDL attribute, as was done forGlobalEventHandlers
.The definition of "policy" suggests that the event could in theory also fire on
WorkletGlobalScope
but that interface does not inherit fromEventTarget
. That seems to be adequately covered by the "Report a violation" algorithm. If firing atWorkletGlobalScope
is also expected, more changes would be needed.