[webrtc-pc] Data channels in workers get initialized on wrong thread (#3063)

jan-ivar has just created a new issue for https://github.com/w3c/webrtc-pc:

== Data channels in workers get initialized on wrong thread ==
The [spec](https://w3c.github.io/webrtc-pc/#dfn-rtcsctptransport-connected) says:
- _"Once an SCTP transport is connected, ... the user agent MUST [queue a task](https://html.spec.whatwg.org/multipage/webappapis.html#queue-a-task) that runs the following steps: ... 4. For each of connection's [RTCDataChannel](https://w3c.github.io/webrtc-pc/#dom-rtcdatachannel): ... 2. If channel.[[[DataChannelId]]](https://w3c.github.io/webrtc-pc/#dfn-datachannelid) is null, initialize [[[DataChannelId]]](https://w3c.github.io/webrtc-pc/#dfn-datachannelid) to the value generated by the underlying sctp data channel, according to [[RFC8832](https://w3c.github.io/webrtc-pc/#bib-rfc8832)]."_

Here, the _"For each of connection's [RTCDataChannel](https://w3c.github.io/webrtc-pc/#dom-rtcdatachannel)"_ is extremely broad, reasonably read as including `RTCDataChannel`s in workers (as opposed to iterating over connection.[[[DataChannels]]](https://w3c.github.io/webrtc-pc/#dfn-datachannels)).

It goes on to initialize each data channel's [[[DataChannelId]]](https://w3c.github.io/webrtc-pc/#dfn-datachannelid) on main-thread, which is bad news if it's in a worker.

I think we need to either:
1. push this down into _"3. ... [announce the channel as open](https://w3c.github.io/webrtc-pc/#announce-datachannel-open)"_ which queues its own (correctly realm-targeted) task per `RTCDataChannel` — a potentially breaking change if anyone expects to read their `datachannel.id`s from their SCTPTransport `statechange` event listener. OR 
2. exclude worker data channels in this for-loop and initialize them separately

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/3063 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 8 July 2025 23:56:47 UTC