Re: [whatwg/dom] AbortSignal consumers can potentialy emit abort event on it (#784)

To me such code example, if not fixed, is only removing any interest to separated the controller from the signal.

If the API is meant to provide a real "protection" that some frameworks, libraries, vendor featured API might want, it should probably be done completely.

(Don't get me wrong @domenic I really appreciate the huge work done on CancelablePromise, and then AbortController)

> There's a lot of potentially surprising cases due to the way JavaScript and the web platform in general work, but this doesn't seem like anything out of the ordinary.

I agree, but I also think that there is a global effort to improve the web platform against existing leaks & inconsistencies. I'm thinking of things like sandboxes, ES `Object.freeze()`/`Object.seal()` & getter properties, upcoming private fields...

```js
controller = new AbortController();
signal = controller.signal;
Object.seal(signal);
Object.defineProperty(signal, "aborted", { value: 1 });

VM165:3 Uncaught TypeError: Cannot define property aborted, object is not extensible
    at Function.defineProperty (<anonymous>)
    at <anonymous>:3:8


console.log(signal.aborted); // false
controller.abort();
console.log(signal.aborted); // true
```

So nothing prevent from enforcing this API isolation if we want a "safe" signal


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/784#issuecomment-530822558