"construct a ReadableStream object" doesn't specify the realm

[jyasskin]

This algorithm is used inside the Fetch spec in https://fetch.spec.whatwg.org/#http-network-fetch, which has a request whose client is either an environment settings object that can provide the realm, or null. It's used outside of Fetch from at least https://w3c.github.io/ServiceWorker/#fetch-event-respondwith, which specifies the Service Worker's realm manually.

[ricea]

"construct a ReadableStream object" is scheduled to be changed to use the CreateReadableStream abstract operation rather than the ReadableStream constructor. However, this just moves the problem around, as CreateReadableStream() creates a ReadableStream object, and the created object needs to be in a specified realm.

[annevk]

@ricea as I mentioned in #731, we could really do with some kind of internal concept of streams at times, so we only have to worry about realms when they get exposed to JavaScript.

I guess we could still make it work somehow, but the whole setup is rather questionable to begin with given that the network thread isn't supposed to run JavaScript.

[ricea]

@annevk Is there a case where a stream is created that could never be observable by Javascript? My impression is that's easier to get the realm right at creation time than try to patch it up later when Javascript looks at it.

The thing that worries me more than realms is Promises. The standard makes extensive use of Promises for asynchronicity, and in principle they're not visible to Javascript and so don't need to be on a thread that runs Javascript, but JS is slippery and what is and isn't observable is hard to pin down.

[annevk]

@ricea e.g., step 9 of https://fetch.spec.whatwg.org/#http-network-fetch cannot be observable (except maybe theoretically for synchronous fetches, but that's more a bug with how we define synchronous fetching) as fetching happens in parallel so at whatever point you get back to the main thread you'll have to allocate a new object.

[ricea]

@annevk Thanks. I see now.

It's regrettable, but it still looks like we can just pretend this all happens in an imaginary JS realm. When transferrable streams are specced we can make this a bit more robust by providing a mechanism for the Uint8Array objects that were created on the network thread to show up on the main thread with the correct realm.

[wanderview]

Aren't we basically talking about native underlying sources here? This is something we've always designed around existing for things like optimization, etc. It seems like it might be useful to actually define it.

[annevk]

@domenic I realized that this remains a problem with the new setup and https://streams.spec.whatwg.org/#readablestream-create doesn't seem to provide hooks for it either.

[domenic]

Yep. Streams in general is still not great about realms; that'd be a good next thing for me to tackle.