onremovestream has been deprecated (and removed from Firefox), while onremovetrack is not yet implemented in Firefox.

How do I detect when a stream or track is being removed in Firefox?

onremovestream has been deprecated (and removed from Firefox), while onremovetrack is not yet implemented in Firefox.

How do I detect when a stream or track is being removed in Firefox?

• javascript
• stream
• webrtc
• peer-connection

• 1 If the user leaves the room then the peerconnection closes and this will trigger oniceconnectionstatechange and also onsignalingstatechange events, both iceConnectionState and signalingState will be 'closed'. – Karthik Commented Mar 11, 2020 at 13:37
• This is correct. However, I am getting a consistent delay between the user leaving the room and oniceconnectionstatechange actually being fired (sometimes). – Daniele Molinari Commented Mar 11, 2020 at 13:46
• @DanieleMolinari Please update your question with more specifics about the problem you're trying to solve. From your ment it sounds like you're trying to detect a remote peer dropping, which has nothing to do with negotiating away a track (which was what onremovestream was for). – jib Commented Mar 22, 2020 at 20:23
• @jib My question originally included an "how to detect when the user leaves the room" part. Since @Karthik is right on the oniceconnectionstatechange, I removed it from the question. What I am trying to solve is the case when a user adds multiple video streams, then removes one. – Daniele Molinari Commented Mar 23, 2020 at 10:10

1 Answer 1

You use onremovetrack on the receiving stream:

pc.ontrack = ({track, streams: [stream]}) => {
  track.onunmute = () => {
    if (!video.srcObject) video.srcObject = stream;
  };
  stream.onremovetrack = ({track}) => {
    console.log(`${track.kind} track was removed.`);
    if (!stream.getTracks().length) {
      console.log(`stream ${stream.id} emptied (effectively removed).`);
    }
  };
};

The above ontrack will run when e.g. the other side adds a track (and negotiates):

const sender = pc.addTrack(track, stream);

Now, whenever that other side calls either pc.removeTrack(sender) or sets transceiver.direction = "recvonly" (and negotiates), you should see the removetrack event fire.

Here's an example that should work in all browsers.

Things to keep in mind

In standard WebRTC ("unified-plan") our transceiver.receiver.track isn't ended when this happens, because it is wired to the other side's transceiver.sender, not the other side's transceiver.sender.track.

Instead of ending, our receiving track is muted and removed from its stream(s).

This is because pc.removeTrack(sender) only sets the sender.track to null and transceiver.direction to recvonly (requiring negotiation).

A sender may thus resume sending data using sender.replaceTrack(newTrack) and setting transceiver.direction = "sendrecv" again. On this happening, our receiver.track would be unmuted again and reinserted into the stream(s), firing the addtrack events on the stream(s). This also fires the track event again. Explore all the events in this blog's interactive section.

A receiving track is only truly ended by transceiver.stop() (locally or through negotiation), or pc.close().