Intent to Ship: Expose ReadableStreamDefaultController interface

[Nidhi Jaju]

Contact emails

nidh...@google.com, ri...@chromium.org

Explainer

https://github.com/whatwg/streams/issues/963
https://github.com/whatwg/streams/pull/1035

Specification

https://streams.spec.whatwg.org/#rs-default-controller-class-definition

API spec

Yes

Summary

The Streams APIs provide ubiquitous, interoperable primitives for creating, composing, and consuming streams of data. We will expose the ReadableStreamDefaultController interface on the global object, as with the other ReadableStream-related classes. This will align Blink with the current version of the Streams API Standard and consensus among the developer community. See https://github.com/whatwg/streams/issues/963.

Blink component

Blink>Network>StreamsAPI

TAG review

There is no TAG review for this since: 

 - It is a tiny change to the interface

 - It does not expose any new functionality 

 - It is already possible to call the ReadableStreamDefaultController constructor explicitly

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Low risk because the Streams API spec has already been standardised for a long time (since around 2014).

Gecko: No signal Jason Orendorff (@jorendorff) reviewed the original PR and gave positive feedback.
WebKit: No signal
Web developers: No signals

Ergonomics

This will move us in line with the standard behaviour for WebIDL-defined classes that are part of the web platform. See https://heycam.github.io/webidl/#NoInterfaceObject and https://heycam.github.io/webidl/#Exposed. This should reduce developer surprise.

Activation

Developers can use this feature immediately, as it does not change the behaviour of existing code. The feature can be polyfilled with one line of JavaScript: new ReadableStream({start(controller) {self.ReadableStreamDefaultController = controller.constructor; }});

Debuggability

No special support needed.

Is this feature fully tested by web-platform-tests?

Yes

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5711333280448512

[yo...@yoav.ws]

On Tuesday, December 8, 2020 at 10:10:59 AM UTC+1 Nidhi Jaju wrote:

Contact emails

nidh...@google.com, ri...@chromium.org

Explainer

https://github.com/whatwg/streams/issues/963
https://github.com/whatwg/streams/pull/1035

Could you provide an inline explanation of what the feature is, what it looks like and how developers are supposed to use it?

[Nidhi Jaju]

Hi Yoav,

The feature is essentially just exposing the ReadableStreamDefaultController on the global object. This means that evaluating 'ReadableStreamDefaultController' in window goes from false to true. Exposing it does not expose any new functionality, so developers are not really affected in any way.

Currently, developers need to write:
new ReadableStream({start(controller) { self.ReadableStreamDefaultController = controller.constructor; }});

to call the ReadableStreamDefaultController constructor.

However, most do not use this anyway, except for maybe in web platform tests, or if they want to wrap the methods for debugging purposes for example. By exposing the interface globally, there is no need to explicitly write this one line of Javascript code anymore.

I've also added this information to the 'Motivation' section to the ChromeStatus entry, so hopefully that helps provide some more clarity/context. Thank you!

Best regards,

Nidhi

[Yoav Weiss]

LGTM1

On Fri, Dec 11, 2020 at 3:59 AM Nidhi Jaju <nidh...@google.com> wrote:

Hi Yoav,

The feature is essentially just exposing the ReadableStreamDefaultController on the global object. This means that evaluating 'ReadableStreamDefaultController' in window goes from false to true. Exposing it does not expose any new functionality, so developers are not really affected in any way.

Currently, developers need to write:
new ReadableStream({start(controller) { self.ReadableStreamDefaultController = controller.constructor; }});
to call the ReadableStreamDefaultController constructor.

However, most do not use this anyway, except for maybe in web platform tests, or if they want to wrap the methods for debugging purposes for example. By exposing the interface globally, there is no need to explicitly write this one line of Javascript code anymore.

I've also added this information to the 'Motivation' section to the ChromeStatus entry, so hopefully that helps provide some more clarity/context. Thank you!

OK, so this is just aligning our behavior to the spec. Got it! :)

[TAMURA, Kent]

LGTM2

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgYDW-TV-pFXhqxvsAVeJdDxmPMbziMND%3D6KtZg-373KA%40mail.gmail.com.

--

TAMURA Kent
Software Engineer, Google

[Daniel Bratell]

LGTM3

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqGnkzE9oUd6RH5%3DsLSGuDy0eYK5%2B2KjnPNiMfGO%3DUYDUg%40mail.gmail.com.

[Domenic Denicola]

Hey all,

Today I was browsing https://wpt.fyi/results/streams?label=experimental&label=master&aligned and noticed that we were failing tests because of an analogous non-exposure of TransformStreamDefaultController. I have a CL to fix this at https://chromium-review.googlesource.com/c/chromium/src/+/3757032 and was thinking it should be OK to just ping this thread with an FYI instead of doing a full Intent to Ship, because the change is basically the same (and in particular is extremely small/just updating to follow the spec/already implemented in other browsers). IMO this does not need a ChromeStatus entry or release blog post spot either.

Does that sound OK? If so hopefully an API owner can stop by my CL and approve the webexposed/ changes. Otherwise we can start a new Intent to Ship thread if necessary.

-Domenic

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgYDW-TV-pFXhqxvsAVeJdDxmPMbziMND%3D6KtZg-373KA%40mail.gmail.com.

--

TAMURA Kent
Software Engineer, Google

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[TAMURA, Kent]

IMO, it's a bug fix and we don't need a dedicated I2S.

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgYDW-TV-pFXhqxvsAVeJdDxmPMbziMND%3D6KtZg-373KA%40mail.gmail.com.

--

TAMURA Kent
Software Engineer, Google

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqGnkzE9oUd6RH5%3DsLSGuDy0eYK5%2B2KjnPNiMfGO%3DUYDUg%40mail.gmail.com.

[Yoav Weiss]

Hey Domenic!

While I agree it's a very similar case, it's not identical.

I agree that a TAG review is not needed here, nor getting positions from other vendors, but there's still some risk in exposing the interface where it wasn't exposed before. (e.g. sites using the lack of exposure for some weird feature detection)

And while I don't think the risk here is high, it's non-zero. E.g. quickly scanning through the HTTPArchive [1], I see ~15K response bodies that contain the string "ReadableStreamDefaultController".

So, I think it'd be good to send out a new intent and discuss the risks and whether we need to do something to counter them (e.g. sampled analysis of HTTPArchive data, ClusterTelemetry run with tighter counters, or maybe nothing at all).

I know it'd create some extra overhead, but would enable us to keep track of this specific change and its current risks.

Cheers,

Yoav

[1]

SELECT page, url

FROM `httparchive.response_bodies.2022_07_01_desktop`

#FROM `httparchive.sample_data.response_bodies_desktop_10k`

WHERE body like "%TransformStreamDefaultController%"

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqE%2BUvBox8ox4rE5Za3e2-8Ts%2ByrgDM5VeR1%2BWu9dLkZ2A%40mail.gmail.com.

[Domenic Denicola]

While I'm happy to do it, I think I may not have explained the situation well enough, so let me ask a clarifying question...

On Tue, Jul 12, 2022 at 3:00 PM Yoav Weiss <yoav...@chromium.org> wrote:

Hey Domenic!

While I agree it's a very similar case, it's not identical. 

I agree that a TAG review is not needed here, nor getting positions from other vendors, but there's still some risk in exposing the interface where it wasn't exposed before. (e.g. sites using the lack of exposure for some weird feature detection)

And while I don't think the risk here is high, it's non-zero. E.g. quickly scanning through the HTTPArchive [1], I see ~15K response bodies that contain the string "ReadableStreamDefaultController".

So, I think it'd be good to send out a new intent and discuss the risks and whether we need to do something to counter them (e.g. sampled analysis of HTTPArchive data, ClusterTelemetry run with tighter counters, or maybe nothing at all).

I know it'd create some extra overhead, but would enable us to keep track of this specific change and its current risks.

What risk would you be imagining? It seems like a high burden to ask people to do HTTPArchive analysis just to fix an exposure bug like this, especially one where all other browsers already expose the global. Like, we don't ask people to do HTTP archive analysis when exposing entire new features which come with multiple new globals, where Chrome is shipping first, so I don't see why this case would need such analysis. Indeed, many Intent to Ships have sailed through the API Owners with "No compat concerns; this is a new feature".

To be clear, I'm willing (if not excited) to spend 2x the time I spent on the CL doing all the ChromeStatus rigamarole and sending an email, if the result is going to be a quick 3 LGTMs because it's trivial and we're just checking some process boxes. I'm not really willing to spend more time than that on this bugfix, though...

[Alex Russell]

Hey Domenic,

Discussed at today's API OWNERS and we decided that:

• It makes sense for this to be an intent
• We're happy to see this skipped for TAG review as it is covered by previous reviews
• You should expect the intent to be fast-tracked once filed, and please just link to this discussion as you file it

Thanks in advance, and sorry for the overhead.

Best,

Alex

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgYDW-TV-pFXhqxvsAVeJdDxmPMbziMND%3D6KtZg-373KA%40mail.gmail.com.

--

TAMURA Kent
Software Engineer, Google

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqGnkzE9oUd6RH5%3DsLSGuDy0eYK5%2B2KjnPNiMfGO%3DUYDUg%40mail.gmail.com.

--

TAMURA Kent
Software Engineer, Google

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Joe Medley]

Gang,

I want to make sure I understand. It seems like this is just a bug fix or something like it. I want to understand before I agree that it doesn't need a mention in the blog post.

Here's what I think it sounds like. The functionality shipped in Chrome 89 as shown on the status entry, but it didn't actually work. Is that correct?

Joe

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgYDW-TV-pFXhqxvsAVeJdDxmPMbziMND%3D6KtZg-373KA%40mail.gmail.com.

--

TAMURA Kent
Software Engineer, Google

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqGnkzE9oUd6RH5%3DsLSGuDy0eYK5%2B2KjnPNiMfGO%3DUYDUg%40mail.gmail.com.

--

TAMURA Kent
Software Engineer, Google

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqE%2BUvBox8ox4rE5Za3e2-8Ts%2ByrgDM5VeR1%2BWu9dLkZ2A%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fdba0f28-667a-4d7f-84fc-91421b041532n%40chromium.org.

[Domenic Denicola]

Thanks Alex! I'll work on the Intent now. A response to Joe's question below.

On Thu, Jul 14, 2022 at 1:10 AM Joe Medley <jme...@google.com> wrote:

Gang,

I want to make sure I understand. It seems like this is just a bug fix or something like it. I want to understand before I agree that it doesn't need a mention in the blog post.

Here's what I think it sounds like. The functionality shipped in Chrome 89 as shown on the status entry, but it didn't actually work. Is that correct?

Not quite. What shipped in Chrome 89 was exposing ReadableStreamDefaultController. What I am proposing to ship in Chrome 105 is the analogous exposure of TransformStreamDefaultController. They are two separate changes, just very similar to each other.

They are both very small bug fixes that IMO are not really that interesting to developers, since they are mostly about spec-conformance in an area developers won't notice directly. So IMO they don't need a mention in the blog post. But, that is not my determination to make, so feel free to judge for yourself when you see the upcoming Intent. It won't hurt anything if it's included.

[Joe Medley]

Domenic,

Thank you for the information.

I dug into this before deciding whether to include it in the blog post. From what I gather in the spec, the only way to get an instance of this is through a number of callbacks (TransformerStartCallback, TransformerFlushCallback, and TransformerTransformCallback). I guess this is what you mean by, "spec-conformance in an area developers won't notice directly." I can't find that Chrome currently implements these. If the callbacks are ever implemented, I'll need a short item about all of them.

For future reference, here's the heuristic for what goes in a blog post. If Chrome get's a platform feature that was not in the previous version, it goes in. Whether something was implemented because of a bug or a formal planning process is not generally something external developers care about. (A single developer might if they tried to use something that was supposed to be available and they're the one that filed the bug. I consider that an edge case.)

Joe

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

[Joe Medley]

Apparently, I missed this so I do intend to add it to the beta post.

let TransformStreamDefaultController;
new TransformStream({ start(c) { TransformStreamDefaultController = c.constructor; } });

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.