Use a restricted version of AddEventListenerOptions?
#66
Comments
This was referenced Sep 15, 2023
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Nov 30, 2023
This CL implements "limited" and "leaky" EventTarget integration with the Observable API. See below for what "limited" and "leaky" mean. Concretely, this involves introducing the `on()` method to the EventTarget interface, so that all EventTargets can return Observables that listen for events. This is the part that really makes Observables a "better addEventListener()". This is the first instance of a natively-constructed Observable, as opposed to a JS-constructed Observable. This means the subscription callback passed to the Observable constructor is not just a JS callback function with user-defined code, but instead is a C++ delegate class, called `SubscribeDelegate` which has its first concrete implementation provided by EventTarget (in event_target.cc). The concrete implementation of this interface that this CL introduces, adds an event listener to the given EventTarget, upon subscription. The events are forwarded to the Subscriber's `next()` method. This is what unlocks more ergonomic event handling with the composable Observable primitive and all of its (coming) operators. 1. The EventTarget integration is considered "limited" because we do not support any of the `AddEventListenerOptions` yet, as of this CL. A subsequent CL will add supported for a more restricted version of the `AddEventListenerOptions`, called `ObservableEventListenerOptions`, which does not include a `once` option, or an `AbortSignal`, since Observable operators and subscription is responsible for managing those aspects. Concretely, an `ObservableEventListenerOptions` will resolve to an `AddEventListenerOptionsResolved` accordingly. See: - WICG/observable#66 - WICG/observable#67 - WICG/observable#65 2. The EventTarget integration is considered "leaky" as of this CL, because there is currently no way to remove an event listener added by an EventTarget-vended Observable. This will come in a subsequent CL, which will pass the test that is currently failing in this CL. See WICG/observable#75 for discussion about tying the subscription termination to removing an event listener. From a technical perspective, this is pretty easy — it involves adding an abort algorithm to `Subscriber#signal` (which has already been wired up properly by now!) that removes the given per-Subscription `ObservableEventListener` NativeEventListener from the associated EventTarget. That implementation has already been sketched out in https://crrev.com/c/4262153 and the design doc. It will included in a follow-up CL, to reduce the complexity of this one. R=masonf@chromium.org Bug: 1485981 Change-Id: Iafeddb0894b8eed2be1d95c181fc44d7650c0d47
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Nov 30, 2023
This CL implements "limited" and "leaky" EventTarget integration with the Observable API. See below for what "limited" and "leaky" mean. Concretely, this involves introducing the `on()` method to the EventTarget interface, so that all EventTargets can return Observables that listen for events. This is the part that really makes Observables a "better addEventListener()". This is the first instance of a natively-constructed Observable, as opposed to a JS-constructed Observable. This means the subscription callback passed to the Observable constructor is not just a JS callback function with user-defined code, but instead is a C++ delegate class, called `SubscribeDelegate` which has its first concrete implementation provided by EventTarget (in event_target.cc). The concrete implementation of this interface that this CL introduces, adds an event listener to the given EventTarget, upon subscription. The events are forwarded to the Subscriber's `next()` method. This is what unlocks more ergonomic event handling with the composable Observable primitive and all of its (coming) operators. 1. The EventTarget integration is considered "limited" because we do not support any of the `AddEventListenerOptions` yet, as of this CL. A subsequent CL will add supported for a more restricted version of the `AddEventListenerOptions`, called `ObservableEventListenerOptions`, which does not include a `once` option, or an `AbortSignal`, since Observable operators and subscription is responsible for managing those aspects. Concretely, an `ObservableEventListenerOptions` will resolve to an `AddEventListenerOptionsResolved` accordingly. See: - WICG/observable#66 - WICG/observable#67 - WICG/observable#65 2. The EventTarget integration is considered "leaky" as of this CL, because there is currently no way to remove an event listener added by an EventTarget-vended Observable. This will come in a subsequent CL, which will pass the test that is currently failing in this CL. See WICG/observable#75 for discussion about tying the subscription termination to removing an event listener. From a technical perspective, this is pretty easy — it involves adding an abort algorithm to `Subscriber#signal` (which has already been wired up properly by now!) that removes the given per-Subscription `ObservableEventListener` NativeEventListener from the associated EventTarget. That implementation has already been sketched out in https://crrev.com/c/4262153 and the design doc. It will included in a follow-up CL, to reduce the complexity of this one. R=masonf@chromium.org Bug: 1485981 Change-Id: Iafeddb0894b8eed2be1d95c181fc44d7650c0d47
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Nov 30, 2023
This CL implements "limited" and "leaky" EventTarget integration with the Observable API. See below for what "limited" and "leaky" mean. Concretely, this involves introducing the `on()` method to the EventTarget interface, so that all EventTargets can return Observables that listen for events. This is the part that really makes Observables a "better addEventListener()". This is the first instance of a natively-constructed Observable, as opposed to a JS-constructed Observable. This means the subscription callback passed to the Observable constructor is not just a JS callback function with user-defined code, but instead is a C++ delegate class, called `SubscribeDelegate` which has its first concrete implementation provided by EventTarget (in event_target.cc). The concrete implementation of this interface that this CL introduces, adds an event listener to the given EventTarget, upon subscription. The events are forwarded to the Subscriber's `next()` method. This is what unlocks more ergonomic event handling with the composable Observable primitive and all of its (coming) operators. 1. The EventTarget integration is considered "limited" because we do not support any of the `AddEventListenerOptions` yet, as of this CL. A subsequent CL will add supported for a more restricted version of the `AddEventListenerOptions`, called `ObservableEventListenerOptions`, which does not include a `once` option, or an `AbortSignal`, since Observable operators and subscription is responsible for managing those aspects. Concretely, an `ObservableEventListenerOptions` will resolve to an `AddEventListenerOptionsResolved` accordingly. See: - WICG/observable#66 - WICG/observable#67 - WICG/observable#65 2. The EventTarget integration is considered "leaky" as of this CL, because there is currently no way to remove an event listener added by an EventTarget-vended Observable. This will come in a subsequent CL, which will pass the test that is currently failing in this CL. See WICG/observable#75 for discussion about tying the subscription termination to removing an event listener. From a technical perspective, this is pretty easy — it involves adding an abort algorithm to `Subscriber#signal` (which has already been wired up properly by now!) that removes the given per-Subscription `ObservableEventListener` NativeEventListener from the associated EventTarget. That implementation has already been sketched out in https://crrev.com/c/4262153 and the design doc. It will included in a follow-up CL, to reduce the complexity of this one. For WPTs: Co-authored-by: ben@benlesh.com R=masonf@chromium.org Bug: 1485981 Change-Id: Iafeddb0894b8eed2be1d95c181fc44d7650c0d47
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Nov 30, 2023
This CL implements "limited" and "leaky" EventTarget integration with the Observable API. See below for what "limited" and "leaky" mean. Concretely, this involves introducing the `on()` method to the EventTarget interface, so that all EventTargets can return Observables that listen for events. This is the part that really makes Observables a "better addEventListener()". This is the first instance of a natively-constructed Observable, as opposed to a JS-constructed Observable. This means the subscription callback passed to the Observable constructor is not just a JS callback function with user-defined code, but instead is a C++ delegate class, called `SubscribeDelegate` which has its first concrete implementation provided by EventTarget (in event_target.cc). The concrete implementation of this interface that this CL introduces, adds an event listener to the given EventTarget, upon subscription. The events are forwarded to the Subscriber's `next()` method. This is what unlocks more ergonomic event handling with the composable Observable primitive and all of its (coming) operators. 1. The EventTarget integration is considered "limited" because we do not support any of the `AddEventListenerOptions` yet, as of this CL. A subsequent CL will add supported for a more restricted version of the `AddEventListenerOptions`, called `ObservableEventListenerOptions`, which does not include a `once` option, or an `AbortSignal`, since Observable operators and subscription is responsible for managing those aspects. Concretely, an `ObservableEventListenerOptions` will resolve to an `AddEventListenerOptionsResolved` accordingly. See: - WICG/observable#66 - WICG/observable#67 - WICG/observable#65 2. The EventTarget integration is considered "leaky" as of this CL, because there is currently no way to remove an event listener added by an EventTarget-vended Observable. This will come in a subsequent CL, which will pass the test that is currently failing in this CL. See WICG/observable#75 for discussion about tying the subscription termination to removing an event listener. From a technical perspective, this is pretty easy — it involves adding an abort algorithm to `Subscriber#signal` (which has already been wired up properly by now!) that removes the given per-Subscription `ObservableEventListener` NativeEventListener from the associated EventTarget. That implementation has already been sketched out in https://crrev.com/c/4262153 and the design doc. It will included in a follow-up CL, to reduce the complexity of this one. For WPTs: Co-authored-by: ben@benlesh.com R=masonf@chromium.org Bug: 1485981 Change-Id: Iafeddb0894b8eed2be1d95c181fc44d7650c0d47
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Dec 1, 2023
This CL implements "limited" and "leaky" EventTarget integration with the Observable API. See below for what "limited" and "leaky" mean. Concretely, this involves introducing the `on()` method to the EventTarget interface, so that all EventTargets can return Observables that listen for events. This is the part that really makes Observables a "better addEventListener()". This is the first instance of a natively-constructed Observable, as opposed to a JS-constructed Observable. This means the subscription callback passed to the Observable constructor is not just a JS callback function with user-defined code, but instead is a C++ delegate class, called `SubscribeDelegate` which has its first concrete implementation provided by EventTarget (in event_target.cc). The concrete implementation of this interface that this CL introduces, adds an event listener to the given EventTarget, upon subscription. The events are forwarded to the Subscriber's `next()` method. This is what unlocks more ergonomic event handling with the composable Observable primitive and all of its (coming) operators. 1. The EventTarget integration is considered "limited" because we do not support any of the `AddEventListenerOptions` yet, as of this CL. A subsequent CL will add supported for a more restricted version of the `AddEventListenerOptions`, called `ObservableEventListenerOptions`, which does not include a `once` option, or an `AbortSignal`, since Observable operators and subscription is responsible for managing those aspects. Concretely, an `ObservableEventListenerOptions` will resolve to an `AddEventListenerOptionsResolved` accordingly. See: - WICG/observable#66 - WICG/observable#67 - WICG/observable#65 2. The EventTarget integration is considered "leaky" as of this CL, because there is currently no way to remove an event listener added by an EventTarget-vended Observable. This will come in a subsequent CL, which will pass the test that is currently failing in this CL. See WICG/observable#75 for discussion about tying the subscription termination to removing an event listener. From a technical perspective, this is pretty easy — it involves adding an abort algorithm to `Subscriber#signal` (which has already been wired up properly by now!) that removes the given per-Subscription `ObservableEventListener` NativeEventListener from the associated EventTarget. That implementation has already been sketched out in https://crrev.com/c/4262153 and the design doc. It will included in a follow-up CL, to reduce the complexity of this one. For WPTs: Co-authored-by: ben@benlesh.com R=masonf@chromium.org Bug: 1485981 Change-Id: Iafeddb0894b8eed2be1d95c181fc44d7650c0d47
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Dec 5, 2023
This CL implements "limited" and "leaky" EventTarget integration with the Observable API. See below for what "limited" and "leaky" mean. Concretely, this involves introducing the `on()` method to the EventTarget interface, so that all EventTargets can return Observables that listen for events. This is the part that really makes Observables a "better addEventListener()". This is the first instance of a natively-constructed Observable, as opposed to a JS-constructed Observable. This means the subscription callback passed to the Observable constructor is not just a JS callback function with user-defined code, but instead is a C++ delegate class, called `SubscribeDelegate` which has its first concrete implementation provided by EventTarget (in event_target.cc). The concrete implementation of this interface that this CL introduces, adds an event listener to the given EventTarget, upon subscription. The events are forwarded to the Subscriber's `next()` method. This is what unlocks more ergonomic event handling with the composable Observable primitive and all of its (coming) operators. 1. The EventTarget integration is considered "limited" because we do not support any of the `AddEventListenerOptions` yet, as of this CL. A subsequent CL will add supported for a more restricted version of the `AddEventListenerOptions`, called `ObservableEventListenerOptions`, which does not include a `once` option, or an `AbortSignal`, since Observable operators and subscription is responsible for managing those aspects. Concretely, an `ObservableEventListenerOptions` will resolve to an `AddEventListenerOptionsResolved` accordingly. See: - WICG/observable#66 - WICG/observable#67 - WICG/observable#65 2. The EventTarget integration is considered "leaky" as of this CL, because there is currently no way to remove an event listener added by an EventTarget-vended Observable. This will come in a subsequent CL, which will pass the test that is currently failing in this CL. See WICG/observable#75 for discussion about tying the subscription termination to removing an event listener. From a technical perspective, this is pretty easy — it involves adding an abort algorithm to `Subscriber#signal` (which has already been wired up properly by now!) that removes the given per-Subscription `ObservableEventListener` NativeEventListener from the associated EventTarget. That implementation has already been sketched out in https://crrev.com/c/4262153 and the design doc. It will included in a follow-up CL, to reduce the complexity of this one. For WPTs: Co-authored-by: ben@benlesh.com R=masonf@chromium.org Bug: 1485981 Change-Id: Iafeddb0894b8eed2be1d95c181fc44d7650c0d47
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Dec 5, 2023
This CL implements "limited" and "leaky" EventTarget integration with the Observable API. See below for what "limited" and "leaky" mean. Concretely, this involves introducing the `on()` method to the EventTarget interface, so that all EventTargets can return Observables that listen for events. This is the part that really makes Observables a "better addEventListener()". This is the first instance of a natively-constructed Observable, as opposed to a JS-constructed Observable. This means the subscription callback passed to the Observable constructor is not just a JS callback function with user-defined code, but instead is a C++ delegate class, called `SubscribeDelegate` which has its first concrete implementation provided by EventTarget (in event_target.cc). The concrete implementation of this interface that this CL introduces, adds an event listener to the given EventTarget, upon subscription. The events are forwarded to the Subscriber's `next()` method. This is what unlocks more ergonomic event handling with the composable Observable primitive and all of its (coming) operators. 1. The EventTarget integration is considered "limited" because we do not support any of the `AddEventListenerOptions` yet, as of this CL. A subsequent CL will add supported for a more restricted version of the `AddEventListenerOptions`, called `ObservableEventListenerOptions`, which does not include a `once` option, or an `AbortSignal`, since Observable operators and subscription is responsible for managing those aspects. Concretely, an `ObservableEventListenerOptions` will resolve to an `AddEventListenerOptionsResolved` accordingly. See: - WICG/observable#66 - WICG/observable#67 - WICG/observable#65 2. The EventTarget integration is considered "leaky" as of this CL, because there is currently no way to remove an event listener added by an EventTarget-vended Observable. This will come in a subsequent CL, which will pass the test that is currently failing in this CL. See WICG/observable#75 for discussion about tying the subscription termination to removing an event listener. From a technical perspective, this is pretty easy — it involves adding an abort algorithm to `Subscriber#signal` (which has already been wired up properly by now!) that removes the given per-Subscription `ObservableEventListener` NativeEventListener from the associated EventTarget. That implementation has already been sketched out in https://crrev.com/c/4262153 and the design doc. It will included in a follow-up CL, to reduce the complexity of this one. For WPTs: Co-authored-by: ben@benlesh.com R=masonf@chromium.org Bug: 1485981 Change-Id: Iafeddb0894b8eed2be1d95c181fc44d7650c0d47
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Dec 5, 2023
This CL implements "limited" and "leaky" EventTarget integration with the Observable API. See below for what "limited" and "leaky" mean. Concretely, this involves introducing the `on()` method to the EventTarget interface, so that all EventTargets can return Observables that listen for events. This is the part that really makes Observables a "better addEventListener()". This is the first instance of a natively-constructed Observable, as opposed to a JS-constructed Observable. This means the subscription callback passed to the Observable constructor is not just a JS callback function with user-defined code, but instead is a C++ delegate class, called `SubscribeDelegate` which has its first concrete implementation provided by EventTarget (in event_target.cc). The concrete implementation of this interface that this CL introduces, adds an event listener to the given EventTarget, upon subscription. The events are forwarded to the Subscriber's `next()` method. This is what unlocks more ergonomic event handling with the composable Observable primitive and all of its (coming) operators. 1. The EventTarget integration is considered "limited" because we do not support any of the `AddEventListenerOptions` yet, as of this CL. A subsequent CL will add supported for a more restricted version of the `AddEventListenerOptions`, called `ObservableEventListenerOptions`, which does not include a `once` option, or an `AbortSignal`, since Observable operators and subscription is responsible for managing those aspects. Concretely, an `ObservableEventListenerOptions` will resolve to an `AddEventListenerOptionsResolved` accordingly. See: - WICG/observable#66 - WICG/observable#67 - WICG/observable#65 2. The EventTarget integration is considered "leaky" as of this CL, because there is currently no way to remove an event listener added by an EventTarget-vended Observable. This will come in a subsequent CL, which will pass the test that is currently failing in this CL. See WICG/observable#75 for discussion about tying the subscription termination to removing an event listener. From a technical perspective, this is pretty easy — it involves adding an abort algorithm to `Subscriber#signal` (which has already been wired up properly by now!) that removes the given per-Subscription `ObservableEventListener` NativeEventListener from the associated EventTarget. That implementation has already been sketched out in https://crrev.com/c/4262153 and the design doc. It will included in a follow-up CL, to reduce the complexity of this one. For WPTs: Co-authored-by: ben@benlesh.com R=masonf@chromium.org Bug: 1485981 Change-Id: Iafeddb0894b8eed2be1d95c181fc44d7650c0d47
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Dec 7, 2023
This CL implements "limited" and "leaky" EventTarget integration with the Observable API. See below for what "limited" and "leaky" mean. Concretely, this involves introducing the `on()` method to the EventTarget interface, so that all EventTargets can return Observables that listen for events. This is the part that really makes Observables a "better addEventListener()". This is the first instance of a natively-constructed Observable, as opposed to a JS-constructed Observable. This means the subscription callback passed to the Observable constructor is not just a JS callback function with user-defined code, but instead is a C++ delegate class, called `SubscribeDelegate` which has its first concrete implementation provided by EventTarget (in event_target.cc). The concrete implementation of this interface that this CL introduces, adds an event listener to the given EventTarget, upon subscription. The events are forwarded to the Subscriber's `next()` method. This is what unlocks more ergonomic event handling with the composable Observable primitive and all of its (coming) operators. 1. The EventTarget integration is considered "limited" because we do not support any of the `AddEventListenerOptions` yet, as of this CL. A subsequent CL will add support for a more restricted version of the `AddEventListenerOptions`, called `ObservableEventListenerOptions`, which does not include a `once` option, or an `AbortSignal`, since Observable operators and subscription is responsible for managing those aspects. Concretely, an `ObservableEventListenerOptions` will resolve to an `AddEventListenerOptionsResolved` accordingly. See: - WICG/observable#66 - WICG/observable#67 - WICG/observable#65 2. The EventTarget integration is considered "leaky" as of this CL, because there is currently no way to remove an event listener added by an EventTarget-vended Observable. This will come in a subsequent CL, which will pass the test that is currently failing in this CL. See WICG/observable#75 for discussion about tying the subscription termination to removing an event listener. From a technical perspective, this is pretty easy — it involves adding an abort algorithm to `Subscriber#signal` (which has already been wired up properly by now!) that removes the given per-Subscription `ObservableEventListener` NativeEventListener from the associated EventTarget. That implementation has already been sketched out in https://crrev.com/c/4262153 and the design doc. It will included in a follow-up CL, to reduce the complexity of this one. For WPTs: Co-authored-by: ben@benlesh.com R=masonf@chromium.org Bug: 1485981 Change-Id: Iafeddb0894b8eed2be1d95c181fc44d7650c0d47
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Dec 7, 2023
This CL implements "limited" and "leaky" EventTarget integration with the Observable API. See below for what "limited" and "leaky" mean. Concretely, this involves introducing the `on()` method to the EventTarget interface, so that all EventTargets can return Observables that listen for events. This is the part that really makes Observables a "better addEventListener()". This is the first instance of a natively-constructed Observable, as opposed to a JS-constructed Observable. This means the subscription callback passed to the Observable constructor is not just a JS callback function with user-defined code, but instead is a C++ delegate class, called `SubscribeDelegate` which has its first concrete implementation provided by EventTarget (in event_target.cc). The concrete implementation of this interface that this CL introduces, adds an event listener to the given EventTarget, upon subscription. The events are forwarded to the Subscriber's `next()` method. This is what unlocks more ergonomic event handling with the composable Observable primitive and all of its (coming) operators. 1. The EventTarget integration is considered "limited" because we do not support any of the `AddEventListenerOptions` yet, as of this CL. A subsequent CL will add support for a more restricted version of the `AddEventListenerOptions`, called `ObservableEventListenerOptions`, which does not include a `once` option, or an `AbortSignal`, since Observable operators and subscription is responsible for managing those aspects. Concretely, an `ObservableEventListenerOptions` will resolve to an `AddEventListenerOptionsResolved` accordingly. See: - WICG/observable#66 - WICG/observable#67 - WICG/observable#65 2. The EventTarget integration is considered "leaky" as of this CL, because there is currently no way to remove an event listener added by an EventTarget-vended Observable. This will come in a subsequent CL, which will pass the test that is currently failing in this CL. See WICG/observable#75 for discussion about tying the subscription termination to removing an event listener. From a technical perspective, this is pretty easy — it involves adding an abort algorithm to `Subscriber#signal` (which has already been wired up properly by now!) that removes the given per-Subscription `ObservableEventListener` NativeEventListener from the associated EventTarget. That implementation has already been sketched out in https://crrev.com/c/4262153 and the design doc. It will included in a follow-up CL, to reduce the complexity of this one. For WPTs: Co-authored-by: ben@benlesh.com R=masonf@chromium.org Bug: 1485981 Change-Id: Iafeddb0894b8eed2be1d95c181fc44d7650c0d47
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Dec 7, 2023
This CL implements "limited" and "leaky" EventTarget integration with the Observable API. See below for what "limited" and "leaky" mean. Concretely, this involves introducing the `on()` method to the EventTarget interface, so that all EventTargets can return Observables that listen for events. This is the part that really makes Observables a "better addEventListener()". This is the first instance of a natively-constructed Observable, as opposed to a JS-constructed Observable. This means the subscription callback passed to the Observable constructor is not just a JS callback function with user-defined code, but instead is a C++ delegate class, called `SubscribeDelegate` which has its first concrete implementation provided by EventTarget (in event_target.cc). The concrete implementation of this interface that this CL introduces, adds an event listener to the given EventTarget, upon subscription. The events are forwarded to the Subscriber's `next()` method. This is what unlocks more ergonomic event handling with the composable Observable primitive and all of its (coming) operators. 1. The EventTarget integration is considered "limited" because we do not support any of the `AddEventListenerOptions` yet, as of this CL. A subsequent CL will add support for a more restricted version of the `AddEventListenerOptions`, called `ObservableEventListenerOptions`, which does not include a `once` option, or an `AbortSignal`, since Observable operators and subscription is responsible for managing those aspects. Concretely, an `ObservableEventListenerOptions` will resolve to an `AddEventListenerOptionsResolved` accordingly. See: - WICG/observable#66 - WICG/observable#67 - WICG/observable#65 2. The EventTarget integration is considered "leaky" as of this CL, because there is currently no way to remove an event listener added by an EventTarget-vended Observable. This will come in a subsequent CL, which will pass the test that is currently failing in this CL. See WICG/observable#75 for discussion about tying the subscription termination to removing an event listener. From a technical perspective, this is pretty easy — it involves adding an abort algorithm to `Subscriber#signal` (which has already been wired up properly by now!) that removes the given per-Subscription `ObservableEventListener` NativeEventListener from the associated EventTarget. That implementation has already been sketched out in https://crrev.com/c/4262153 and the design doc. It will included in a follow-up CL, to reduce the complexity of this one. For WPTs: Co-authored-by: ben@benlesh.com R=masonf@chromium.org Bug: 1485981 Change-Id: Iafeddb0894b8eed2be1d95c181fc44d7650c0d47
aarongable
pushed a commit
to chromium/chromium
that referenced
this issue
Dec 14, 2023
This CL implements "limited" and "leaky" EventTarget integration with the Observable API. See below for what "limited" and "leaky" mean. Concretely, this involves introducing the `on()` method to the EventTarget interface, so that all EventTargets can return Observables that listen for events. This is the part that really makes Observables a "better addEventListener()". This is the first instance of a natively-constructed Observable, as opposed to a JS-constructed Observable. This means the subscription callback passed to the Observable constructor is not just a JS callback function with user-defined code, but instead is a C++ delegate class, called `SubscribeDelegate` which has its first concrete implementation provided by EventTarget (in event_target.cc). The concrete implementation of this interface that this CL introduces, adds an event listener to the given EventTarget, upon subscription. The events are forwarded to the Subscriber's `next()` method. This is what unlocks more ergonomic event handling with the composable Observable primitive and all of its (coming) operators. 1. The EventTarget integration is considered "limited" because we do not support any of the `AddEventListenerOptions` yet, as of this CL. A subsequent CL will add support for a more restricted version of the `AddEventListenerOptions`, called `ObservableEventListenerOptions`, which does not include a `once` option, or an `AbortSignal`, since Observable operators and subscription is responsible for managing those aspects. Concretely, an `ObservableEventListenerOptions` will resolve to an `AddEventListenerOptionsResolved` accordingly. See: - WICG/observable#66 - WICG/observable#67 - WICG/observable#65 2. The EventTarget integration is considered "leaky" as of this CL, because there is currently no way to remove an event listener added by an EventTarget-vended Observable. This will come in a subsequent CL, which will pass the test that is currently failing in this CL. See WICG/observable#75 for discussion about tying the subscription termination to removing an event listener. From a technical perspective, this is pretty easy — it involves adding an abort algorithm to `Subscriber#signal` (which has already been wired up properly by now!) that removes the given per-Subscription `ObservableEventListener` NativeEventListener from the associated EventTarget. That implementation has already been sketched out in https://crrev.com/c/4262153 and the design doc. It will included in a follow-up CL, to reduce the complexity of this one. For WPTs: Co-authored-by: ben@benlesh.com R=masonf@chromium.org Bug: 1485981 Change-Id: Iafeddb0894b8eed2be1d95c181fc44d7650c0d47 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5073394 Reviewed-by: Mason Freed <masonf@chromium.org> Commit-Queue: Dominic Farolino <dom@chromium.org> Cr-Commit-Position: refs/heads/main@{#1237501}
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Dec 14, 2023
This CL implements "limited" and "leaky" EventTarget integration with the Observable API. See below for what "limited" and "leaky" mean. Concretely, this involves introducing the `on()` method to the EventTarget interface, so that all EventTargets can return Observables that listen for events. This is the part that really makes Observables a "better addEventListener()". This is the first instance of a natively-constructed Observable, as opposed to a JS-constructed Observable. This means the subscription callback passed to the Observable constructor is not just a JS callback function with user-defined code, but instead is a C++ delegate class, called `SubscribeDelegate` which has its first concrete implementation provided by EventTarget (in event_target.cc). The concrete implementation of this interface that this CL introduces, adds an event listener to the given EventTarget, upon subscription. The events are forwarded to the Subscriber's `next()` method. This is what unlocks more ergonomic event handling with the composable Observable primitive and all of its (coming) operators. 1. The EventTarget integration is considered "limited" because we do not support any of the `AddEventListenerOptions` yet, as of this CL. A subsequent CL will add support for a more restricted version of the `AddEventListenerOptions`, called `ObservableEventListenerOptions`, which does not include a `once` option, or an `AbortSignal`, since Observable operators and subscription is responsible for managing those aspects. Concretely, an `ObservableEventListenerOptions` will resolve to an `AddEventListenerOptionsResolved` accordingly. See: - WICG/observable#66 - WICG/observable#67 - WICG/observable#65 2. The EventTarget integration is considered "leaky" as of this CL, because there is currently no way to remove an event listener added by an EventTarget-vended Observable. This will come in a subsequent CL, which will pass the test that is currently failing in this CL. See WICG/observable#75 for discussion about tying the subscription termination to removing an event listener. From a technical perspective, this is pretty easy — it involves adding an abort algorithm to `Subscriber#signal` (which has already been wired up properly by now!) that removes the given per-Subscription `ObservableEventListener` NativeEventListener from the associated EventTarget. That implementation has already been sketched out in https://crrev.com/c/4262153 and the design doc. It will included in a follow-up CL, to reduce the complexity of this one. For WPTs: Co-authored-by: ben@benlesh.com R=masonf@chromium.org Bug: 1485981 Change-Id: Iafeddb0894b8eed2be1d95c181fc44d7650c0d47 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5073394 Reviewed-by: Mason Freed <masonf@chromium.org> Commit-Queue: Dominic Farolino <dom@chromium.org> Cr-Commit-Position: refs/heads/main@{#1237501}
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Dec 14, 2023
This CL implements "limited" and "leaky" EventTarget integration with the Observable API. See below for what "limited" and "leaky" mean. Concretely, this involves introducing the `on()` method to the EventTarget interface, so that all EventTargets can return Observables that listen for events. This is the part that really makes Observables a "better addEventListener()". This is the first instance of a natively-constructed Observable, as opposed to a JS-constructed Observable. This means the subscription callback passed to the Observable constructor is not just a JS callback function with user-defined code, but instead is a C++ delegate class, called `SubscribeDelegate` which has its first concrete implementation provided by EventTarget (in event_target.cc). The concrete implementation of this interface that this CL introduces, adds an event listener to the given EventTarget, upon subscription. The events are forwarded to the Subscriber's `next()` method. This is what unlocks more ergonomic event handling with the composable Observable primitive and all of its (coming) operators. 1. The EventTarget integration is considered "limited" because we do not support any of the `AddEventListenerOptions` yet, as of this CL. A subsequent CL will add support for a more restricted version of the `AddEventListenerOptions`, called `ObservableEventListenerOptions`, which does not include a `once` option, or an `AbortSignal`, since Observable operators and subscription is responsible for managing those aspects. Concretely, an `ObservableEventListenerOptions` will resolve to an `AddEventListenerOptionsResolved` accordingly. See: - WICG/observable#66 - WICG/observable#67 - WICG/observable#65 2. The EventTarget integration is considered "leaky" as of this CL, because there is currently no way to remove an event listener added by an EventTarget-vended Observable. This will come in a subsequent CL, which will pass the test that is currently failing in this CL. See WICG/observable#75 for discussion about tying the subscription termination to removing an event listener. From a technical perspective, this is pretty easy — it involves adding an abort algorithm to `Subscriber#signal` (which has already been wired up properly by now!) that removes the given per-Subscription `ObservableEventListener` NativeEventListener from the associated EventTarget. That implementation has already been sketched out in https://crrev.com/c/4262153 and the design doc. It will included in a follow-up CL, to reduce the complexity of this one. For WPTs: Co-authored-by: ben@benlesh.com R=masonf@chromium.org Bug: 1485981 Change-Id: Iafeddb0894b8eed2be1d95c181fc44d7650c0d47 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5073394 Reviewed-by: Mason Freed <masonf@chromium.org> Commit-Queue: Dominic Farolino <dom@chromium.org> Cr-Commit-Position: refs/heads/main@{#1237501}
moz-v2v-gh
pushed a commit
to mozilla/gecko-dev
that referenced
this issue
Dec 15, 2023
…1/N, a=testonly Automatic update from web-platform-tests DOM: Observable EventTarget integration 1/N This CL implements "limited" and "leaky" EventTarget integration with the Observable API. See below for what "limited" and "leaky" mean. Concretely, this involves introducing the `on()` method to the EventTarget interface, so that all EventTargets can return Observables that listen for events. This is the part that really makes Observables a "better addEventListener()". This is the first instance of a natively-constructed Observable, as opposed to a JS-constructed Observable. This means the subscription callback passed to the Observable constructor is not just a JS callback function with user-defined code, but instead is a C++ delegate class, called `SubscribeDelegate` which has its first concrete implementation provided by EventTarget (in event_target.cc). The concrete implementation of this interface that this CL introduces, adds an event listener to the given EventTarget, upon subscription. The events are forwarded to the Subscriber's `next()` method. This is what unlocks more ergonomic event handling with the composable Observable primitive and all of its (coming) operators. 1. The EventTarget integration is considered "limited" because we do not support any of the `AddEventListenerOptions` yet, as of this CL. A subsequent CL will add support for a more restricted version of the `AddEventListenerOptions`, called `ObservableEventListenerOptions`, which does not include a `once` option, or an `AbortSignal`, since Observable operators and subscription is responsible for managing those aspects. Concretely, an `ObservableEventListenerOptions` will resolve to an `AddEventListenerOptionsResolved` accordingly. See: - WICG/observable#66 - WICG/observable#67 - WICG/observable#65 2. The EventTarget integration is considered "leaky" as of this CL, because there is currently no way to remove an event listener added by an EventTarget-vended Observable. This will come in a subsequent CL, which will pass the test that is currently failing in this CL. See WICG/observable#75 for discussion about tying the subscription termination to removing an event listener. From a technical perspective, this is pretty easy — it involves adding an abort algorithm to `Subscriber#signal` (which has already been wired up properly by now!) that removes the given per-Subscription `ObservableEventListener` NativeEventListener from the associated EventTarget. That implementation has already been sketched out in https://crrev.com/c/4262153 and the design doc. It will included in a follow-up CL, to reduce the complexity of this one. For WPTs: Co-authored-by: ben@benlesh.com R=masonf@chromium.org Bug: 1485981 Change-Id: Iafeddb0894b8eed2be1d95c181fc44d7650c0d47 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5073394 Reviewed-by: Mason Freed <masonf@chromium.org> Commit-Queue: Dominic Farolino <dom@chromium.org> Cr-Commit-Position: refs/heads/main@{#1237501} -- wpt-commits: aeeea4221bce5c44edeb8adad0296bbd68a4af71 wpt-pr: 43455
gecko-dev-updater
pushed a commit
to marco-c/gecko-dev-wordified-and-comments-removed
that referenced
this issue
Dec 16, 2023
…1/N, a=testonly Automatic update from web-platform-tests DOM: Observable EventTarget integration 1/N This CL implements "limited" and "leaky" EventTarget integration with the Observable API. See below for what "limited" and "leaky" mean. Concretely, this involves introducing the `on()` method to the EventTarget interface, so that all EventTargets can return Observables that listen for events. This is the part that really makes Observables a "better addEventListener()". This is the first instance of a natively-constructed Observable, as opposed to a JS-constructed Observable. This means the subscription callback passed to the Observable constructor is not just a JS callback function with user-defined code, but instead is a C++ delegate class, called `SubscribeDelegate` which has its first concrete implementation provided by EventTarget (in event_target.cc). The concrete implementation of this interface that this CL introduces, adds an event listener to the given EventTarget, upon subscription. The events are forwarded to the Subscriber's `next()` method. This is what unlocks more ergonomic event handling with the composable Observable primitive and all of its (coming) operators. 1. The EventTarget integration is considered "limited" because we do not support any of the `AddEventListenerOptions` yet, as of this CL. A subsequent CL will add support for a more restricted version of the `AddEventListenerOptions`, called `ObservableEventListenerOptions`, which does not include a `once` option, or an `AbortSignal`, since Observable operators and subscription is responsible for managing those aspects. Concretely, an `ObservableEventListenerOptions` will resolve to an `AddEventListenerOptionsResolved` accordingly. See: - WICG/observable#66 - WICG/observable#67 - WICG/observable#65 2. The EventTarget integration is considered "leaky" as of this CL, because there is currently no way to remove an event listener added by an EventTarget-vended Observable. This will come in a subsequent CL, which will pass the test that is currently failing in this CL. See WICG/observable#75 for discussion about tying the subscription termination to removing an event listener. From a technical perspective, this is pretty easy — it involves adding an abort algorithm to `Subscriber#signal` (which has already been wired up properly by now!) that removes the given per-Subscription `ObservableEventListener` NativeEventListener from the associated EventTarget. That implementation has already been sketched out in https://crrev.com/c/4262153 and the design doc. It will included in a follow-up CL, to reduce the complexity of this one. For WPTs: Co-authored-by: benbenlesh.com R=masonfchromium.org Bug: 1485981 Change-Id: Iafeddb0894b8eed2be1d95c181fc44d7650c0d47 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5073394 Reviewed-by: Mason Freed <masonfchromium.org> Commit-Queue: Dominic Farolino <domchromium.org> Cr-Commit-Position: refs/heads/main{#1237501} -- wpt-commits: aeeea4221bce5c44edeb8adad0296bbd68a4af71 wpt-pr: 43455 UltraBlame original commit: 152cc51982905b4522338a38f9542e691a6a93e3
gecko-dev-updater
pushed a commit
to marco-c/gecko-dev-wordified
that referenced
this issue
Dec 16, 2023
…1/N, a=testonly Automatic update from web-platform-tests DOM: Observable EventTarget integration 1/N This CL implements "limited" and "leaky" EventTarget integration with the Observable API. See below for what "limited" and "leaky" mean. Concretely, this involves introducing the `on()` method to the EventTarget interface, so that all EventTargets can return Observables that listen for events. This is the part that really makes Observables a "better addEventListener()". This is the first instance of a natively-constructed Observable, as opposed to a JS-constructed Observable. This means the subscription callback passed to the Observable constructor is not just a JS callback function with user-defined code, but instead is a C++ delegate class, called `SubscribeDelegate` which has its first concrete implementation provided by EventTarget (in event_target.cc). The concrete implementation of this interface that this CL introduces, adds an event listener to the given EventTarget, upon subscription. The events are forwarded to the Subscriber's `next()` method. This is what unlocks more ergonomic event handling with the composable Observable primitive and all of its (coming) operators. 1. The EventTarget integration is considered "limited" because we do not support any of the `AddEventListenerOptions` yet, as of this CL. A subsequent CL will add support for a more restricted version of the `AddEventListenerOptions`, called `ObservableEventListenerOptions`, which does not include a `once` option, or an `AbortSignal`, since Observable operators and subscription is responsible for managing those aspects. Concretely, an `ObservableEventListenerOptions` will resolve to an `AddEventListenerOptionsResolved` accordingly. See: - WICG/observable#66 - WICG/observable#67 - WICG/observable#65 2. The EventTarget integration is considered "leaky" as of this CL, because there is currently no way to remove an event listener added by an EventTarget-vended Observable. This will come in a subsequent CL, which will pass the test that is currently failing in this CL. See WICG/observable#75 for discussion about tying the subscription termination to removing an event listener. From a technical perspective, this is pretty easy — it involves adding an abort algorithm to `Subscriber#signal` (which has already been wired up properly by now!) that removes the given per-Subscription `ObservableEventListener` NativeEventListener from the associated EventTarget. That implementation has already been sketched out in https://crrev.com/c/4262153 and the design doc. It will included in a follow-up CL, to reduce the complexity of this one. For WPTs: Co-authored-by: benbenlesh.com R=masonfchromium.org Bug: 1485981 Change-Id: Iafeddb0894b8eed2be1d95c181fc44d7650c0d47 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5073394 Reviewed-by: Mason Freed <masonfchromium.org> Commit-Queue: Dominic Farolino <domchromium.org> Cr-Commit-Position: refs/heads/main{#1237501} -- wpt-commits: aeeea4221bce5c44edeb8adad0296bbd68a4af71 wpt-pr: 43455 UltraBlame original commit: 152cc51982905b4522338a38f9542e691a6a93e3
gecko-dev-updater
pushed a commit
to marco-c/gecko-dev-comments-removed
that referenced
this issue
Dec 16, 2023
…1/N, a=testonly Automatic update from web-platform-tests DOM: Observable EventTarget integration 1/N This CL implements "limited" and "leaky" EventTarget integration with the Observable API. See below for what "limited" and "leaky" mean. Concretely, this involves introducing the `on()` method to the EventTarget interface, so that all EventTargets can return Observables that listen for events. This is the part that really makes Observables a "better addEventListener()". This is the first instance of a natively-constructed Observable, as opposed to a JS-constructed Observable. This means the subscription callback passed to the Observable constructor is not just a JS callback function with user-defined code, but instead is a C++ delegate class, called `SubscribeDelegate` which has its first concrete implementation provided by EventTarget (in event_target.cc). The concrete implementation of this interface that this CL introduces, adds an event listener to the given EventTarget, upon subscription. The events are forwarded to the Subscriber's `next()` method. This is what unlocks more ergonomic event handling with the composable Observable primitive and all of its (coming) operators. 1. The EventTarget integration is considered "limited" because we do not support any of the `AddEventListenerOptions` yet, as of this CL. A subsequent CL will add support for a more restricted version of the `AddEventListenerOptions`, called `ObservableEventListenerOptions`, which does not include a `once` option, or an `AbortSignal`, since Observable operators and subscription is responsible for managing those aspects. Concretely, an `ObservableEventListenerOptions` will resolve to an `AddEventListenerOptionsResolved` accordingly. See: - WICG/observable#66 - WICG/observable#67 - WICG/observable#65 2. The EventTarget integration is considered "leaky" as of this CL, because there is currently no way to remove an event listener added by an EventTarget-vended Observable. This will come in a subsequent CL, which will pass the test that is currently failing in this CL. See WICG/observable#75 for discussion about tying the subscription termination to removing an event listener. From a technical perspective, this is pretty easy — it involves adding an abort algorithm to `Subscriber#signal` (which has already been wired up properly by now!) that removes the given per-Subscription `ObservableEventListener` NativeEventListener from the associated EventTarget. That implementation has already been sketched out in https://crrev.com/c/4262153 and the design doc. It will included in a follow-up CL, to reduce the complexity of this one. For WPTs: Co-authored-by: benbenlesh.com R=masonfchromium.org Bug: 1485981 Change-Id: Iafeddb0894b8eed2be1d95c181fc44d7650c0d47 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5073394 Reviewed-by: Mason Freed <masonfchromium.org> Commit-Queue: Dominic Farolino <domchromium.org> Cr-Commit-Position: refs/heads/main{#1237501} -- wpt-commits: aeeea4221bce5c44edeb8adad0296bbd68a4af71 wpt-pr: 43455 UltraBlame original commit: 152cc51982905b4522338a38f9542e691a6a93e3
aosmond
pushed a commit
to aosmond/gecko
that referenced
this issue
Dec 16, 2023
…1/N, a=testonly Automatic update from web-platform-tests DOM: Observable EventTarget integration 1/N This CL implements "limited" and "leaky" EventTarget integration with the Observable API. See below for what "limited" and "leaky" mean. Concretely, this involves introducing the `on()` method to the EventTarget interface, so that all EventTargets can return Observables that listen for events. This is the part that really makes Observables a "better addEventListener()". This is the first instance of a natively-constructed Observable, as opposed to a JS-constructed Observable. This means the subscription callback passed to the Observable constructor is not just a JS callback function with user-defined code, but instead is a C++ delegate class, called `SubscribeDelegate` which has its first concrete implementation provided by EventTarget (in event_target.cc). The concrete implementation of this interface that this CL introduces, adds an event listener to the given EventTarget, upon subscription. The events are forwarded to the Subscriber's `next()` method. This is what unlocks more ergonomic event handling with the composable Observable primitive and all of its (coming) operators. 1. The EventTarget integration is considered "limited" because we do not support any of the `AddEventListenerOptions` yet, as of this CL. A subsequent CL will add support for a more restricted version of the `AddEventListenerOptions`, called `ObservableEventListenerOptions`, which does not include a `once` option, or an `AbortSignal`, since Observable operators and subscription is responsible for managing those aspects. Concretely, an `ObservableEventListenerOptions` will resolve to an `AddEventListenerOptionsResolved` accordingly. See: - WICG/observable#66 - WICG/observable#67 - WICG/observable#65 2. The EventTarget integration is considered "leaky" as of this CL, because there is currently no way to remove an event listener added by an EventTarget-vended Observable. This will come in a subsequent CL, which will pass the test that is currently failing in this CL. See WICG/observable#75 for discussion about tying the subscription termination to removing an event listener. From a technical perspective, this is pretty easy — it involves adding an abort algorithm to `Subscriber#signal` (which has already been wired up properly by now!) that removes the given per-Subscription `ObservableEventListener` NativeEventListener from the associated EventTarget. That implementation has already been sketched out in https://crrev.com/c/4262153 and the design doc. It will included in a follow-up CL, to reduce the complexity of this one. For WPTs: Co-authored-by: ben@benlesh.com R=masonf@chromium.org Bug: 1485981 Change-Id: Iafeddb0894b8eed2be1d95c181fc44d7650c0d47 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5073394 Reviewed-by: Mason Freed <masonf@chromium.org> Commit-Queue: Dominic Farolino <dom@chromium.org> Cr-Commit-Position: refs/heads/main@{#1237501} -- wpt-commits: aeeea4221bce5c44edeb8adad0296bbd68a4af71 wpt-pr: 43455
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The current explainer takes an
AddEventListenerOptionsdictionary on EventTarget#on, which gives us:I think
captureandpassivedefinitely make sense for Observables, butonceandsignalfeel weird. Theonceparameter feels redundant withtake(1)(or maybefirst()which is currently commented-out in our IDL sketch, but maybe it'll make it into the final one...), andsignaldefinitely seems redundant with with the signal that subscribe would get insubscribe({signal}), and it isn't really clear how the "outer" signal (passed in viaAddEventListenerOptions) would even work... I don't think it could be used to remove the event listener, because that would be what the subscriber's signal would be used for. Maybe it'd be used to somehow "cancel" many subscribers to a single observable all at once? Not sure how that'd work. My proposal is that we get rid of these two members from our proposal by using a restricted dictionary that doesn't include them.The text was updated successfully, but these errors were encountered: