Re: [whatwg/streams] Setting Object.prototype.then permits interfering with pipeTo() internals (#933)

Agh, great find.

> I am pretty sure from the definition of CreateIterResultObject() that the iterator object is supposed to be created in the realm of the page.

It should be created in the "current realm", which will be the realm of the pipeTo() function. Not sure whether that helps or hurts, because the confusing test setup... Probably doesn't help enough.

> Use a special variant of CreateIterResultObject() that sets a null prototype on the iterator object.

The problem here is that this means the following code would break, right?

```js
const result = await reader.read();

console.log(result.hasOwnProperty("done"));
```

This would also be inconsistent with all other iter-result objects on the platform, which makes me uncomfortable.

As such it seems like we'd need to pursue option (1)? Which seems quite painful. Although we're vague on how "reads" and "writes" are performed, we explicitly use operations like ReadableStreamCancel that bottom out in CreateIterResultObject(undefined, true), and are thus susceptible to this issue. The best I can think of is adding a flag to all the operations that tells them to use a null-prototype CreateIterResultObject() variant and only using that from pipeTo().

Maybe it'd be worth thinking about what a simpler/more optimized pipeTo() implementation would be and coding that more directly into the standard? For example, not creating promises that are never seen or are consumed only by spec code.

-- 
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/streams/issues/933#issuecomment-400447397