Re: [whatwg/streams] Resolving promises with byte sequences results in UB (Issue #1178)

I apologize for the game of telephone that's been going on (I'll partially blame timezones here). 

So, here's my take on this. I'm implementing ReadableStreams in Firefox using DOM technologies and WebIDL by following the current specification as best I can. 

The test case [`response-stream-with-broken-then.any.js`](https://searchfox.org/mozilla-central/source/testing/web-platform/tests/fetch/api/response/response-stream-with-broken-then.any.js#4-24) tries to ensure that if `Object.prototype.then` is set, it is un-observable via `Response.text()`

In our prototype implementation of this, what happens is we end up calling ReadableStreamDefaultReaderRead as part of the stream processing (which in turn calls ReadableStreamDefaultController.[[PullSteps]], then the [readRequest's chunk steps](https://streams.spec.whatwg.org/#default-reader-read), which resolves the promise with " «[ "value" → chunk, "done" → false ]»."

Now, as I understand it, the type of this value should be a  ReadableStreamDefaultReadResult. However, the IDL semantics of resolving a promise with an IDL type first converts it to an object, which then resolves the promise. At this point, in our implementation, the original value is lost, and replaced by the value returned by `Object.prototype.then`. 

Now one place I'm not entirely comfortable is that I've essentially used the same structure of implementation that our previous JS implementation used when it comes to integrating with system provided streams. I have found it challenging to map the Fetch spec to our implementation, but have something largely working... except for this. Ultimately what I have implemented is treating our native stream system as if it was a `NativeUnderlyingSource`, as if such a type existed. This is quite nice because it means that the majority of our implementation integrates with ReadableStreams very pleasantly.

My read on this is still that it's a specification issue, but it's complex because of the layering and I'm _definitely_ not an expert on how fetch is supposed to work. As I say earlier.. I have a hard time mapping our implementation to spec. 

-- 
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/1178#issuecomment-948053884