How should MediaStreamTrack interact with BFCache?

[fergald]

If a MediaStreamTrack is live when navigating away from the page, what should happen? Some possibilities (based on my very limited knowledge of MediaStreamTrack).

1. page is not salvageable (cannot enter BFCache)
2. page is salvageable (can enter BFCache)
   1. track becomes ended, event is delivered to JS
   2. track stays live. If the page is restored, things continue on as before

Are there other options? I would very much prefer to no do 1.

@alvestrand @guidou please add people from Moz and Safari if possible.

[youennf]

@jan-ivar

[youennf]

In Safari, page is salvageable even if it has MediaStreamTracks:

• If the track is a capture track (generated by getUserMedia or getDisplayMedia), the track is stopped as we do not want capture to be restored. We queue an ended event which will be delivered if the page is ever restored.
• If the track is not a capture track (canvas, RTCPeerConnection, web audio), the track stays alive (that does not prevent things to happen to the source objects like RTCPeerConnection).

[jan-ivar]

Firefox uses option 1 today but we'd love to get away from it if possible.

I like the Safari behavior described above, but webcompat seems questionable since websites handle ended poorly.

I simulated it in Firefox by removing Allowed Temporarily ✕ in the URL bar's permission dropdown (which won't block):

Does website recover from cam+mic ended?	cam	mic
Meet (in room)	✅ automatic	❌ unrecoverable
Zoom (in room)	✅ after user toggle	❌ unrecoverable
Teams (in room)	✅ after user toggle	✅ after user toggle
Webex (in room)	✅ after user toggle	❌ unrecoverable
Whereby (in room)	❌ unrecoverable	✅ automatic
Jitsi (in room)	❌ unrecoverable¹	❌ unrecoverable¹
Facebook (calling...)	✅ after toggle in ⚙️	✅ after toggle in ⚙️

Of course ↻ is a fine workaround, but some outreach would seem necessary to improve this.

@youennf somewhat related, what does Safari do with BFCache of connected/unconnected RTCPeerConnections?

---

_{1. Not counting users with 2+ devices able to recover by flipping device back and forth.}

[youennf]

webcompat seems questionable since websites handle ended poorly.

ended happens already for other cases that are worth fixing, so having a single mechanism to evangelise is a good thing.

what does Safari do with BFCache of connected/unconnected RTCPeerConnections?

We are shutting down the TCP/UDP connections.

[fergald]

@jan-ivar thanks for doing the research. I feel like if the event already exists and is something that clients should already be handling (even if some are not) then we compat is less of a concern. These clients are already somewhat broken. BFCache will make that worse but also probably cause it to be fixed pretty quickly.

@alvestrand for a Chrome media-centric opinion.

[dontcallmedom-bot]

This issue was discussed in WebRTC February 2024 meeting – 20 February 2024 (How should MediaStreamTrack interact with BFCache?)