Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The steps in "Update the connection state" say to fire connectionstatechange when [[IsClosed]] is set to true #2865

Closed
docfaraday opened this issue Apr 27, 2023 · 2 comments · Fixed by #2876
Assignees

Comments

@docfaraday
Copy link
Contributor

From 4.4.1.3 Update the connection state:

"An RTCPeerConnection object has an aggregated [[ConnectionState]]. Whenever the state of an RTCDtlsTransport changes or when the [[IsClosed]] slot turns true, the user agent MUST update the connection state by queueing a task that runs the following steps:

  1. Let connection be this RTCPeerConnection object.

  2. Let newState be the value of deriving a new state value as described by the RTCPeerConnectionState enum.

  3. If connection.[[ConnectionState]] is equal to newState, abort these steps.

  4. Set connection.[[ConnectionState]] to newState.

  5. Fire an event named connectionstatechange at connection."

This directly contradicts 4.4.4 Garbage collection:

"An RTCPeerConnection object MUST not be garbage collected as long as any event can cause an event handler to be triggered on the object. When the object's [[IsClosed]] internal slot is true, no such event handler can be triggered and it is therefore safe to garbage collect the object."

In addition, most places suppress event firing when [[IsClosed]] is true. There are some exceptions, though, and those are likely bugs too. Just grep through for "Fire an event" and find the places that don't do an [[IsClosed]] check.

@jan-ivar
Copy link
Member

jan-ivar commented Jun 2, 2023

Based on https://jsfiddle.net/jib1/dpxq5nvr/30 (click the Close! button) it looks like no browser fires the connectionstatechange on pc.close(). So we probably want to align the spec with implementations here.

That said, they all appear to fire statechange on sender.transport on pc.close(), so we probably want to keep that. But that's a different section.

@jan-ivar
Copy link
Member

jan-ivar commented Jun 2, 2023

That said, they all appear to fire statechange on sender.transport on pc.close(), so we probably want to keep that.

@docfaraday Given that we're likely to keep this exception, I don't think we can do a PR to blanket suppress event firing when [[IsClosed]] is true. I think we have to open an issue for each one and consider its web compat impact.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants