Re: [blink-dev] Intent to Implement and Ship : onsecuritypolicyviolation event handler IDL attribute

2021-10-28 Thread Manuel Rego Casasnovas
This will ship in M97.

Cheers,
  Rego

On 27/10/2021 19:24, 'Joe Medley' via blink-dev wrote:
> Hi,
> 
> In which version of Chrome do you hope to ship?
> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com
>  | 816-678-7195
> /If an API's not documented it doesn't exist./
> 
> 
> On Thu, Oct 21, 2021 at 11:14 AM Daniel Bratell  > wrote:
> 
> Indeed, so I'm making my LGTM2 on the other thread into an LGTM3 on
> this thread.
> 
> /Daniel
> 
> On 2021-10-21 09:08, Yoav Weiss wrote:
>> LGTM2 to catch up here
>>
>> (Apparently we have 2 intent emails for this..)
>>
>> On Thu, Oct 21, 2021 at 3:50 AM TAMURA, Kent > > wrote:
>>
>> LGTM1.  It's a small straight-forward change.
>>
>>
>>
>> On Thu, Oct 21, 2021 at 12:44 AM > > wrote:
>>
>> Contact emails
>> ssin...@igalia.com ,
>> fw...@chromium.org 
>>
>> Explainer:
>> The securitypolicyviolation event is already implemented
>> in all
>> browsers, one can find document on
>> 
>> MDN(https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onsecuritypolicyviolation
>> 
>> ,
>> 
>> https://developer.mozilla.org/en-US/docs/Web/API/Element/securitypolicyviolation_event
>> 
>> ).
>> The securitypolicyviolation event is dispatched when there
>> is a Content
>> Security Policy violation. Typically, the JS code of the
>> web component
>> will listen to securitypolicyviolation events and react
>> with necessary
>> updates.
>>
>> One could just use addEventListener, but for convenience
>> and consistency
>> with other events (e.g. slotchange) it makes sense to add
>> a IDL
>> onsecuritypolicyviolation attribute which also reflect the
>> attribute on
>> elements. We recently shipped slotchange idl attriubte as well
>> 
>> (https://groups.google.com/a/chromium.org/g/blink-dev/c/cagoIboJ6Oo/m/yje1mcIUBAAJ
>> 
>> )
>>
>> Developers are habitual to use EventTarget.onload = ...
>> and > onload="..."> , but if this does not work for all events,
>> it will be
>> surprising.
>>
>> Currently, the way to listen an event is:
>> target.addEventListener("securitypolicyviolation",
>> mylistener);
>>
>> After this addition an alternative attribute-based form
>> will be
>> availlable for the developers
>> element
>> 
>>
>> Doc Link(s):
>> -
>> https://html.spec.whatwg.org/#handler-onsecuritypolicyviolation
>> 
>> - https://github.com/whatwg/html/pull/2651
>> 
>> -
>> https://chromium-review.googlesource.com/c/chromium/src/+/3226366
>> 
>> 
>>
>> Specification
>> https://html.spec.whatwg.org 
>>
>> Summary
>> The securitypolicyviolation event is fired when a Content
>> Security
>> Policy is violated.One can listen to that event via the
>> EventTarget.addEventListener() API. The goal is now to
>> expose the
>> onsecuritypolicyviolation IDL attribute from the
>> GlobalEventHandlers
>> interface, so that one can register a listener by
>> attaching this
>> attribute to target elements.
>>
>> Blink component
>> Blink>DOM
>>
>> Motivation
>> The securitypolicyviolation event is fired when a Content
>> Security
>> Policy is violated.
>> One can naturally listen to that event via the
>> EventTarget.addEventListener() API. However, web
>> developers are also
>> familiar with the alternative attribute-based form (e.g.
>> element.addEventListener("securitypolicyviolation
>> ", ...) Vs on )
>> which is sometimes convenient for quick testing. For
>> consistency with
>> other events, an attribute

Re: [blink-dev] Intent to Implement and Ship : onsecuritypolicyviolation event handler IDL attribute

2021-10-27 Thread 'Joe Medley' via blink-dev
Hi,

In which version of Chrome do you hope to ship?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Thu, Oct 21, 2021 at 11:14 AM Daniel Bratell  wrote:

> Indeed, so I'm making my LGTM2 on the other thread into an LGTM3 on this
> thread.
>
> /Daniel
> On 2021-10-21 09:08, Yoav Weiss wrote:
>
> LGTM2 to catch up here
>
> (Apparently we have 2 intent emails for this..)
>
> On Thu, Oct 21, 2021 at 3:50 AM TAMURA, Kent  wrote:
>
>> LGTM1.  It's a small straight-forward change.
>>
>>
>>
>> On Thu, Oct 21, 2021 at 12:44 AM  wrote:
>>
>>> Contact emails
>>> ssin...@igalia.com, fw...@chromium.org
>>>
>>> Explainer:
>>> The securitypolicyviolation event is already implemented in all
>>> browsers, one can find document on
>>> MDN(
>>> https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onsecuritypolicyviolation
>>> ,
>>>
>>> https://developer.mozilla.org/en-US/docs/Web/API/Element/securitypolicyviolation_event
>>> ).
>>> The securitypolicyviolation event is dispatched when there is a Content
>>> Security Policy violation. Typically, the JS code of the web component
>>> will listen to securitypolicyviolation events and react with necessary
>>> updates.
>>>
>>> One could just use addEventListener, but for convenience and consistency
>>> with other events (e.g. slotchange) it makes sense to add a IDL
>>> onsecuritypolicyviolation attribute which also reflect the attribute on
>>> elements. We recently shipped slotchange idl attriubte as well
>>> (
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/cagoIboJ6Oo/m/yje1mcIUBAAJ
>>> )
>>>
>>> Developers are habitual to use EventTarget.onload = ... and >> onload="..."> , but if this does not work for all events, it will be
>>> surprising.
>>>
>>> Currently, the way to listen an event is:
>>> target.addEventListener("securitypolicyviolation", mylistener);
>>>
>>> After this addition an alternative attribute-based form will be
>>> availlable for the developers
>>> element
>>> 
>>>
>>> Doc Link(s):
>>> - https://html.spec.whatwg.org/#handler-onsecuritypolicyviolation
>>> - https://github.com/whatwg/html/pull/2651
>>> - https://chromium-review.googlesource.com/c/chromium/src/+/3226366
>>>
>>> Specification
>>> https://html.spec.whatwg.org
>>>
>>> Summary
>>> The securitypolicyviolation event is fired when a Content Security
>>> Policy is violated.One can listen to that event via the
>>> EventTarget.addEventListener() API. The goal is now to expose the
>>> onsecuritypolicyviolation IDL attribute from the GlobalEventHandlers
>>> interface, so that one can register a listener by attaching this
>>> attribute to target elements.
>>>
>>> Blink component
>>> Blink>DOM
>>>
>>> Motivation
>>> The securitypolicyviolation event is fired when a Content Security
>>> Policy is violated.
>>> One can naturally listen to that event via the
>>> EventTarget.addEventListener() API. However, web developers are also
>>> familiar with the alternative attribute-based form (e.g.
>>> element.addEventListener("securitypolicyviolation
>>> ", ...) Vs on )
>>> which is sometimes convenient for quick testing. For consistency with
>>> other events, an attribute onsecuritypolicyviolation is thus added.
>>>
>>> TAG review
>>> TAG review status
>>> This is just a small change to an existing spec implemented in browsers
>>> and discussed at WHATWG
>>>
>>> Risks
>>> Interoperability and Compatibility
>>>
>>> Gecko:
>>> Shipped/Shipping (https://bugzilla.mozilla.org/show_bug.cgi?id=1727302)
>>>
>>> WebKit:
>>> Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=229381)
>>>
>>> Web developers:
>>> N/A
>>>
>>> Debuggability
>>> No DevTools changes are required, treated like any other
>>> event/attribute.
>>>
>>> Is this feature fully tested by web-platform-tests?
>>> Yes
>>>
>>> Web Platform Tests:
>>> w3c/web-platform-tests/dom/idlharness.window.html
>>>
>>> w3c/web-platform-tests/html/webappapis/scripting/events/event-handler-all-global-events.html
>>>
>>> w3c/web-platform-tests/html/webappapis/scripting/events/event-handler-attributes-body-window-expected.txt
>>>
>>>
>>> w3c/web-platform-tests/mathml/relations/html5-tree/math-global-event-handlers.tentative.html
>>>
>>>
>>> Requires code in //chrome?
>>> False
>>>
>>> Tracking bug
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1242893
>>>
>>> Patch:
>>> https://chromium-review.googlesource.com/c/chromium/src/+/3226366
>>>
>>> Estimated milestones
>>> -
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://www.chromestatus.com/features/5639484386312192
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to blink-dev+unsubscr...@chromium.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/35dc5869ac062cb1fd0e8d9bca3f05e3%40ig

Re: [blink-dev] Intent to Implement and Ship : onsecuritypolicyviolation event handler IDL attribute

2021-10-21 Thread Daniel Bratell

This got 3 LGTMs on a different thread.

On 2021-10-21 19:57, Daniel Bratell wrote:


LGTM2

/Daniel

On 2021-10-21 08:34, Yoav Weiss wrote:

LGTM1 to catch up with other implementations on this.


On Wed, Oct 20, 2021 at 5:41 PM Sonia Singla  wrote:

Contact emails

ssin...@igalia.com,

fw...@chromium.org

Explainer:

The securitypolicyviolation event is already implemented in all
browsers, one can find document on

MDN(https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onsecuritypolicyviolation

,

https://developer.mozilla.org/en-US/docs/Web/API/Element/securitypolicyviolation_event

).
The securitypolicyviolation event is dispatched when there is
aContent Security Policy
violation.
Typically, the JS code of the web component will listen to
securitypolicyviolation events and react with necessary updates.

One could just use addEventListener, but for convenience and
consistency with other events (e.g. slotchange) it makes sense to
add a IDL onsecuritypolicyviolation attribute.We recently shipped
onslotchange idl attribute as well. See -

https://groups.google.com/a/chromium.org/g/blink-dev/c/cagoIboJ6Oo/m/aCjiL_FBAgAJ

Developers are used to use EventTarget.onload = ... and  , but if this does not work for all events, it will
be surprising.

Currently, the way to listen an event is:

target.addEventListener("securitypolicyviolation", mylistener);

After this addition an alternative attribute-based form will be

availlable for the developers

element



Doc Link(s):

- https://html.spec.whatwg.org/#handler-onsecuritypolicyviolation


- https://github.com/whatwg/html/pull/2651


-
https://chromium-review.googlesource.com/c/chromium/src/+/3226366


Specification

https://html.spec.whatwg.org 

Summary

The securitypolicyviolation event is fired when a Content
Security Policy is violated.One can listen to that event via the
EventTarget.addEventListener() API. The goal is now to expose the
onsecuritypolicyviolation IDL attribute from the
GlobalEventHandlers interface, so that one can register a
listener by attaching this attribute to target elements.

Blink component

Blink>DOM

Motivation

The securitypolicyviolation event is fired when a Content
Security Policy is violated.

One can naturally listen to that event via the

EventTarget.addEventListener() API. However, web developers are also

familiar with the alternative attribute-based form (e.g.

element.addEventListener("securitypolicyviolation

", ...) Vs on )

which is sometimes convenient for quick testing. For consistency with

other events, an attribute onsecuritypolicyviolation is thus added.

TAG review

TAG review status

This is  asmall change to an existing spec implemented in
browsers and discussed at WHATWG -
https://github.com/whatwg/html/pull/2651,
https://github.com/w3c/webappsec-csp/issues/184


Agree that a TAG review is not needed in this case.


Risks

Interoperability and Compatibility

Gecko:

Shipped/Shipping
(https://bugzilla.mozilla.org/show_bug.cgi?id=1727302)

WebKit:

Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=229381)

Web developers:

N/A

Debuggability

No DevTools changes are required, treated like any other
event/attribute.

Is this feature fully tested by web-platform-tests?

Yes

Web Platform Tests:

1.

w3c/web-platform-tests/dom/idlharness.window.html

2.


w3c/web-platform-tests/html/webappapis/scripting/events/event-handler-all-global-events.html

3.


w3c/web-platform-tests/html/webappapis/scripting/events/event-handler-attributes-body-window-expected.txt


4.


w3c/web-platform-tests/mathml/relations/html5-tree/math-global-event-handlers.tentative.html

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1242893

Patch:

https://chromium-review.googlesource.com/c/chromium/src/+/3226366

Estimated milestones

-

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/features/5639484386312192

-- 
You received this message because you are subscribed to the

Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to

Re: [blink-dev] Intent to Implement and Ship : onsecuritypolicyviolation event handler IDL attribute

2021-10-21 Thread Daniel Bratell
Indeed, so I'm making my LGTM2 on the other thread into an LGTM3 on this 
thread.


/Daniel

On 2021-10-21 09:08, Yoav Weiss wrote:

LGTM2 to catch up here

(Apparently we have 2 intent emails for this..)

On Thu, Oct 21, 2021 at 3:50 AM TAMURA, Kent  wrote:

LGTM1.  It's a small straight-forward change.



On Thu, Oct 21, 2021 at 12:44 AM  wrote:

Contact emails
ssin...@igalia.com, fw...@chromium.org

Explainer:
The securitypolicyviolation event is already implemented in all
browsers, one can find document on

MDN(https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onsecuritypolicyviolation,

https://developer.mozilla.org/en-US/docs/Web/API/Element/securitypolicyviolation_event).
The securitypolicyviolation event is dispatched when there is
a Content
Security Policy violation. Typically, the JS code of the web
component
will listen to securitypolicyviolation events and react with
necessary
updates.

One could just use addEventListener, but for convenience and
consistency
with other events (e.g. slotchange) it makes sense to add a IDL
onsecuritypolicyviolation attribute which also reflect the
attribute on
elements. We recently shipped slotchange idl attriubte as well

(https://groups.google.com/a/chromium.org/g/blink-dev/c/cagoIboJ6Oo/m/yje1mcIUBAAJ)

Developers are habitual to use EventTarget.onload = ... and
 , but if this does not work for all events, it
will be
surprising.

Currently, the way to listen an event is:
target.addEventListener("securitypolicyviolation", mylistener);

After this addition an alternative attribute-based form will be
availlable for the developers
element


Doc Link(s):
- https://html.spec.whatwg.org/#handler-onsecuritypolicyviolation
- https://github.com/whatwg/html/pull/2651
-
https://chromium-review.googlesource.com/c/chromium/src/+/3226366

Specification
https://html.spec.whatwg.org

Summary
The securitypolicyviolation event is fired when a Content Security
Policy is violated.One can listen to that event via the
EventTarget.addEventListener() API. The goal is now to expose the
onsecuritypolicyviolation IDL attribute from the
GlobalEventHandlers
interface, so that one can register a listener by attaching this
attribute to target elements.

Blink component
Blink>DOM

Motivation
The securitypolicyviolation event is fired when a Content Security
Policy is violated.
One can naturally listen to that event via the
EventTarget.addEventListener() API. However, web developers
are also
familiar with the alternative attribute-based form (e.g.
element.addEventListener("securitypolicyviolation
", ...) Vs on )
which is sometimes convenient for quick testing. For
consistency with
other events, an attribute onsecuritypolicyviolation is thus
added.

TAG review
TAG review status
This is just a small change to an existing spec implemented in
browsers
and discussed at WHATWG

Risks
Interoperability and Compatibility

Gecko:
Shipped/Shipping
(https://bugzilla.mozilla.org/show_bug.cgi?id=1727302)

WebKit:
Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=229381)

Web developers:
N/A

Debuggability
No DevTools changes are required, treated like any other
event/attribute.

Is this feature fully tested by web-platform-tests?
Yes

Web Platform Tests:
w3c/web-platform-tests/dom/idlharness.window.html

w3c/web-platform-tests/html/webappapis/scripting/events/event-handler-all-global-events.html

w3c/web-platform-tests/html/webappapis/scripting/events/event-handler-attributes-body-window-expected.txt


w3c/web-platform-tests/mathml/relations/html5-tree/math-global-event-handlers.tentative.html


Requires code in //chrome?
False

Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1242893

Patch:
https://chromium-review.googlesource.com/c/chromium/src/+/3226366

Estimated milestones
-

Link to entry on the Chrome Platform Status
https://www.chromestatus.com/features/5639484386312192

-- 
You received this message because you are subscribed to the

Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to blink-dev+unsubscr...@chromium.org
.
To view this disc

Re: [blink-dev] Intent to Implement and Ship : onsecuritypolicyviolation event handler IDL attribute

2021-10-21 Thread Daniel Bratell

LGTM2

/Daniel

On 2021-10-21 08:34, Yoav Weiss wrote:

LGTM1 to catch up with other implementations on this.


On Wed, Oct 20, 2021 at 5:41 PM Sonia Singla  wrote:

Contact emails

ssin...@igalia.com,

fw...@chromium.org

Explainer:

The securitypolicyviolation event is already implemented in all
browsers, one can find document on

MDN(https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onsecuritypolicyviolation

,

https://developer.mozilla.org/en-US/docs/Web/API/Element/securitypolicyviolation_event

).
The securitypolicyviolation event is dispatched when there is
aContent Security Policy
violation.
Typically, the JS code of the web component will listen to
securitypolicyviolation events and react with necessary updates.

One could just use addEventListener, but for convenience and
consistency with other events (e.g. slotchange) it makes sense to
add a IDL onsecuritypolicyviolation attribute.We recently shipped
onslotchange idl attribute as well. See -

https://groups.google.com/a/chromium.org/g/blink-dev/c/cagoIboJ6Oo/m/aCjiL_FBAgAJ

Developers are used to use EventTarget.onload = ... and  , but if this does not work for all events, it will
be surprising.

Currently, the way to listen an event is:

target.addEventListener("securitypolicyviolation", mylistener);

After this addition an alternative attribute-based form will be

availlable for the developers

element



Doc Link(s):

- https://html.spec.whatwg.org/#handler-onsecuritypolicyviolation


- https://github.com/whatwg/html/pull/2651


-
https://chromium-review.googlesource.com/c/chromium/src/+/3226366


Specification

https://html.spec.whatwg.org 

Summary

The securitypolicyviolation event is fired when a Content Security
Policy is violated.One can listen to that event via the
EventTarget.addEventListener() API. The goal is now to expose the
onsecuritypolicyviolation IDL attribute from the
GlobalEventHandlers interface, so that one can register a listener
by attaching this attribute to target elements.

Blink component

Blink>DOM

Motivation

The securitypolicyviolation event is fired when a Content Security
Policy is violated.

One can naturally listen to that event via the

EventTarget.addEventListener() API. However, web developers are also

familiar with the alternative attribute-based form (e.g.

element.addEventListener("securitypolicyviolation

", ...) Vs on )

which is sometimes convenient for quick testing. For consistency with

other events, an attribute onsecuritypolicyviolation is thus added.

TAG review

TAG review status

This is  asmall change to an existing spec implemented in browsers
and discussed at WHATWG -
https://github.com/whatwg/html/pull/2651,
https://github.com/w3c/webappsec-csp/issues/184


Agree that a TAG review is not needed in this case.


Risks

Interoperability and Compatibility

Gecko:

Shipped/Shipping
(https://bugzilla.mozilla.org/show_bug.cgi?id=1727302)

WebKit:

Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=229381)

Web developers:

N/A

Debuggability

No DevTools changes are required, treated like any other
event/attribute.

Is this feature fully tested by web-platform-tests?

Yes

Web Platform Tests:

1.

w3c/web-platform-tests/dom/idlharness.window.html

2.


w3c/web-platform-tests/html/webappapis/scripting/events/event-handler-all-global-events.html

3.


w3c/web-platform-tests/html/webappapis/scripting/events/event-handler-attributes-body-window-expected.txt


4.


w3c/web-platform-tests/mathml/relations/html5-tree/math-global-event-handlers.tentative.html

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1242893

Patch:

https://chromium-review.googlesource.com/c/chromium/src/+/3226366

Estimated milestones

-

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/features/5639484386312192

-- 
You received this message because you are subscribed to the Google

Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit

Re: [blink-dev] Intent to Implement and Ship : onsecuritypolicyviolation event handler IDL attribute

2021-10-21 Thread Yoav Weiss
LGTM2 to catch up here

(Apparently we have 2 intent emails for this..)

On Thu, Oct 21, 2021 at 3:50 AM TAMURA, Kent  wrote:

> LGTM1.  It's a small straight-forward change.
>
>
>
> On Thu, Oct 21, 2021 at 12:44 AM  wrote:
>
>> Contact emails
>> ssin...@igalia.com, fw...@chromium.org
>>
>> Explainer:
>> The securitypolicyviolation event is already implemented in all
>> browsers, one can find document on
>> MDN(
>> https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onsecuritypolicyviolation
>> ,
>>
>> https://developer.mozilla.org/en-US/docs/Web/API/Element/securitypolicyviolation_event
>> ).
>> The securitypolicyviolation event is dispatched when there is a Content
>> Security Policy violation. Typically, the JS code of the web component
>> will listen to securitypolicyviolation events and react with necessary
>> updates.
>>
>> One could just use addEventListener, but for convenience and consistency
>> with other events (e.g. slotchange) it makes sense to add a IDL
>> onsecuritypolicyviolation attribute which also reflect the attribute on
>> elements. We recently shipped slotchange idl attriubte as well
>> (
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/cagoIboJ6Oo/m/yje1mcIUBAAJ
>> )
>>
>> Developers are habitual to use EventTarget.onload = ... and > onload="..."> , but if this does not work for all events, it will be
>> surprising.
>>
>> Currently, the way to listen an event is:
>> target.addEventListener("securitypolicyviolation", mylistener);
>>
>> After this addition an alternative attribute-based form will be
>> availlable for the developers
>> element
>> 
>>
>> Doc Link(s):
>> - https://html.spec.whatwg.org/#handler-onsecuritypolicyviolation
>> - https://github.com/whatwg/html/pull/2651
>> - https://chromium-review.googlesource.com/c/chromium/src/+/3226366
>>
>> Specification
>> https://html.spec.whatwg.org
>>
>> Summary
>> The securitypolicyviolation event is fired when a Content Security
>> Policy is violated.One can listen to that event via the
>> EventTarget.addEventListener() API. The goal is now to expose the
>> onsecuritypolicyviolation IDL attribute from the GlobalEventHandlers
>> interface, so that one can register a listener by attaching this
>> attribute to target elements.
>>
>> Blink component
>> Blink>DOM
>>
>> Motivation
>> The securitypolicyviolation event is fired when a Content Security
>> Policy is violated.
>> One can naturally listen to that event via the
>> EventTarget.addEventListener() API. However, web developers are also
>> familiar with the alternative attribute-based form (e.g.
>> element.addEventListener("securitypolicyviolation
>> ", ...) Vs on )
>> which is sometimes convenient for quick testing. For consistency with
>> other events, an attribute onsecuritypolicyviolation is thus added.
>>
>> TAG review
>> TAG review status
>> This is just a small change to an existing spec implemented in browsers
>> and discussed at WHATWG
>>
>> Risks
>> Interoperability and Compatibility
>>
>> Gecko:
>> Shipped/Shipping (https://bugzilla.mozilla.org/show_bug.cgi?id=1727302)
>>
>> WebKit:
>> Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=229381)
>>
>> Web developers:
>> N/A
>>
>> Debuggability
>> No DevTools changes are required, treated like any other
>> event/attribute.
>>
>> Is this feature fully tested by web-platform-tests?
>> Yes
>>
>> Web Platform Tests:
>> w3c/web-platform-tests/dom/idlharness.window.html
>>
>> w3c/web-platform-tests/html/webappapis/scripting/events/event-handler-all-global-events.html
>>
>> w3c/web-platform-tests/html/webappapis/scripting/events/event-handler-attributes-body-window-expected.txt
>>
>>
>> w3c/web-platform-tests/mathml/relations/html5-tree/math-global-event-handlers.tentative.html
>>
>>
>> Requires code in //chrome?
>> False
>>
>> Tracking bug
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1242893
>>
>> Patch:
>> https://chromium-review.googlesource.com/c/chromium/src/+/3226366
>>
>> Estimated milestones
>> -
>>
>> Link to entry on the Chrome Platform Status
>> https://www.chromestatus.com/features/5639484386312192
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/35dc5869ac062cb1fd0e8d9bca3f05e3%40igalia.com
>> .
>>
>
>
> --
> TAMURA Kent
> Software Engineer, Google
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqFNhQ6QYFP9pyYe3Xtx5LHZdty%3DopoMRWSjy%3DOg-exdtQ%40mail.gmail.com
> 

Re: [blink-dev] Intent to Implement and Ship : onsecuritypolicyviolation event handler IDL attribute

2021-10-20 Thread Yoav Weiss
LGTM1 to catch up with other implementations on this.


On Wed, Oct 20, 2021 at 5:41 PM Sonia Singla  wrote:

> Contact emails
>
> ssin...@igalia.com,
>
> fw...@chromium.org
>
> Explainer:
>
> The securitypolicyviolation event is already implemented in all browsers,
> one can find document on MDN(
> https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onsecuritypolicyviolation,
>
> https://developer.mozilla.org/en-US/docs/Web/API/Element/securitypolicyviolation_event).
> The securitypolicyviolation event is dispatched when there is a Content
> Security Policy 
> violation. Typically, the JS code of the web component will listen to
> securitypolicyviolation events and react with necessary updates.
>
> One could just use addEventListener, but for convenience and consistency
> with other events (e.g. slotchange) it makes sense to add a IDL
> onsecuritypolicyviolation attribute.We recently shipped onslotchange idl
> attribute as well. See -
> https://groups.google.com/a/chromium.org/g/blink-dev/c/cagoIboJ6Oo/m/aCjiL_FBAgAJ
>
> Developers are used to use EventTarget.onload = ... and  onload="..."> , but if this does not work for all events, it will be
> surprising.
>
> Currently, the way to listen an event is:
>
> target.addEventListener("securitypolicyviolation", mylistener);
>
> After this addition an alternative attribute-based form will be
>
> availlable for the developers
>
> element
>
> 
> Doc Link(s):
>
> - https://html.spec.whatwg.org/#handler-onsecuritypolicyviolation
> 
>
> - https://github.com/whatwg/html/pull/2651
> 
>
> - https://chromium-review.googlesource.com/c/chromium/src/+/3226366
> 
>
> Specification
>
> https://html.spec.whatwg.org
>
> Summary
>
> The securitypolicyviolation event is fired when a Content Security Policy
> is violated.One can listen to that event via the
> EventTarget.addEventListener() API. The goal is now to expose the
> onsecuritypolicyviolation IDL attribute from the GlobalEventHandlers
> interface, so that one can register a listener by attaching this attribute
> to target elements.
>
> Blink component
>
> Blink>DOM
>
> Motivation
>
> The securitypolicyviolation event is fired when a Content Security Policy
> is violated.
>
> One can naturally listen to that event via the
>
> EventTarget.addEventListener() API. However, web developers are also
>
> familiar with the alternative attribute-based form (e.g.
>
> element.addEventListener("securitypolicyviolation
>
> ", ...) Vs on )
>
> which is sometimes convenient for quick testing. For consistency with
>
> other events, an attribute onsecuritypolicyviolation is thus added.
>
> TAG review
>
> TAG review status
>
> This is  asmall change to an existing spec implemented in browsers and
> discussed at WHATWG - https://github.com/whatwg/html/pull/2651,
> https://github.com/w3c/webappsec-csp/issues/184
>

Agree that a TAG review is not needed in this case.


>
> Risks
>
> Interoperability and Compatibility
>
> Gecko:
>
> Shipped/Shipping (https://bugzilla.mozilla.org/show_bug.cgi?id=1727302)
>
> WebKit:
>
> Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=229381)
> Web developers:
>
> N/A
>
> Debuggability
>
> No DevTools changes are required, treated like any other event/attribute.
> Is this feature fully tested by web-platform-tests?
>
> Yes
> Web Platform Tests:
>
>1.
>
>w3c/web-platform-tests/dom/idlharness.window.html
>2.
>
>
>
> w3c/web-platform-tests/html/webappapis/scripting/events/event-handler-all-global-events.html
>3.
>
>
>
> w3c/web-platform-tests/html/webappapis/scripting/events/event-handler-attributes-body-window-expected.txt
>4.
>
>
>
> w3c/web-platform-tests/mathml/relations/html5-tree/math-global-event-handlers.tentative.html
>
> Requires code in //chrome?
>
> False
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1242893
> Patch:
>
> https://chromium-review.googlesource.com/c/chromium/src/+/3226366
>
> Estimated milestones
>
> -
>
> Link to entry on the Chrome Platform Status
>
> https://www.chromestatus.com/features/5639484386312192
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/77047bf5-496b-41cc-9cf8-bcc0fcf9562bn%40chromium.org
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop rec

Re: [blink-dev] Intent to Implement and Ship : onsecuritypolicyviolation event handler IDL attribute

2021-10-20 Thread TAMURA, Kent
LGTM1.  It's a small straight-forward change.



On Thu, Oct 21, 2021 at 12:44 AM  wrote:

> Contact emails
> ssin...@igalia.com, fw...@chromium.org
>
> Explainer:
> The securitypolicyviolation event is already implemented in all
> browsers, one can find document on
> MDN(
> https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onsecuritypolicyviolation
> ,
>
> https://developer.mozilla.org/en-US/docs/Web/API/Element/securitypolicyviolation_event
> ).
> The securitypolicyviolation event is dispatched when there is a Content
> Security Policy violation. Typically, the JS code of the web component
> will listen to securitypolicyviolation events and react with necessary
> updates.
>
> One could just use addEventListener, but for convenience and consistency
> with other events (e.g. slotchange) it makes sense to add a IDL
> onsecuritypolicyviolation attribute which also reflect the attribute on
> elements. We recently shipped slotchange idl attriubte as well
> (
> https://groups.google.com/a/chromium.org/g/blink-dev/c/cagoIboJ6Oo/m/yje1mcIUBAAJ
> )
>
> Developers are habitual to use EventTarget.onload = ... and  onload="..."> , but if this does not work for all events, it will be
> surprising.
>
> Currently, the way to listen an event is:
> target.addEventListener("securitypolicyviolation", mylistener);
>
> After this addition an alternative attribute-based form will be
> availlable for the developers
> element
> 
>
> Doc Link(s):
> - https://html.spec.whatwg.org/#handler-onsecuritypolicyviolation
> - https://github.com/whatwg/html/pull/2651
> - https://chromium-review.googlesource.com/c/chromium/src/+/3226366
>
> Specification
> https://html.spec.whatwg.org
>
> Summary
> The securitypolicyviolation event is fired when a Content Security
> Policy is violated.One can listen to that event via the
> EventTarget.addEventListener() API. The goal is now to expose the
> onsecuritypolicyviolation IDL attribute from the GlobalEventHandlers
> interface, so that one can register a listener by attaching this
> attribute to target elements.
>
> Blink component
> Blink>DOM
>
> Motivation
> The securitypolicyviolation event is fired when a Content Security
> Policy is violated.
> One can naturally listen to that event via the
> EventTarget.addEventListener() API. However, web developers are also
> familiar with the alternative attribute-based form (e.g.
> element.addEventListener("securitypolicyviolation
> ", ...) Vs on )
> which is sometimes convenient for quick testing. For consistency with
> other events, an attribute onsecuritypolicyviolation is thus added.
>
> TAG review
> TAG review status
> This is just a small change to an existing spec implemented in browsers
> and discussed at WHATWG
>
> Risks
> Interoperability and Compatibility
>
> Gecko:
> Shipped/Shipping (https://bugzilla.mozilla.org/show_bug.cgi?id=1727302)
>
> WebKit:
> Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=229381)
>
> Web developers:
> N/A
>
> Debuggability
> No DevTools changes are required, treated like any other
> event/attribute.
>
> Is this feature fully tested by web-platform-tests?
> Yes
>
> Web Platform Tests:
> w3c/web-platform-tests/dom/idlharness.window.html
>
> w3c/web-platform-tests/html/webappapis/scripting/events/event-handler-all-global-events.html
>
> w3c/web-platform-tests/html/webappapis/scripting/events/event-handler-attributes-body-window-expected.txt
>
>
> w3c/web-platform-tests/mathml/relations/html5-tree/math-global-event-handlers.tentative.html
>
>
> Requires code in //chrome?
> False
>
> Tracking bug
> https://bugs.chromium.org/p/chromium/issues/detail?id=1242893
>
> Patch:
> https://chromium-review.googlesource.com/c/chromium/src/+/3226366
>
> Estimated milestones
> -
>
> Link to entry on the Chrome Platform Status
> https://www.chromestatus.com/features/5639484386312192
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/35dc5869ac062cb1fd0e8d9bca3f05e3%40igalia.com
> .
>


-- 
TAMURA Kent
Software Engineer, Google

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqFNhQ6QYFP9pyYe3Xtx5LHZdty%3DopoMRWSjy%3DOg-exdtQ%40mail.gmail.com.