Keep connection on tab switch

[simbleau]

Something that has us with our heads spinning is why webtransport closes connections currently in Chrome when the user switches tabs.

This is contrary to web sockets, which are scoped to the browser instead of a tab.

It's important for many use cases, e.g.

• Listening to streamed audio on a different tab
• Not getting disconnected on a web game when switching tabs

Should this be underscored as a standard for downstream implementers, e.g. Chrome / Firefox?

[jan-ivar]

Hi @simbleau, are you sure the connection is closed and not merely throttled?

Something that has us with our heads spinning is why webtransport closes connections currently in Chrome when the user switches tabs.

What do you mean by "user switches tabs"? If you're seeing Chrome drop connections from a document no longer having focus or no longer being visible, then that sounds like an implementation bug, and you should file an issue with that vendor.

Both WebSocket and WebTransport connections are tied to the Document (webpage), whose lifetime is generally understood to survive tab switching, so there should be no need to call it out in this spec.

@vasilvv I wonder could the background webpage be experiencing throttling?

[MOZGIII]

As part of our discussion at the https://github.com/cBournhonesque/lightyear/issues/144 the issue we might be facing is a combination of the losing tab focus and Chrome's Energy Saving functionality, which would, it seems like, unload the Document, thus losing the WebTransport session. As a workaround for this, we've explored playing audio on the tab to prevent its eviction - but it is not a great solution, so we are bringing it here. This is a TLDR of https://github.com/cBournhonesque/lightyear/issues/144.

To me it seems like things like Energy Saving should also be standardized, or at least their behaviour should be understood and explicitly accounted for in the standards. Maybe we need a "Wake Lock" API for explicitly keeping contexts alive.

[martinthomson]

Wake lock only works because the site is visible and therefore somewhat accountable to the user as a result. Having a way for background tabs to keep themselves alive indefinitely without any sort of feedback would not be a desirable outcome.

A more elegant way to signal a pending (and maybe then imminent) interruption of service might still work.

[ricea]

For some use cases, closing the WebTransport when the page becomes hidden and reopening it when it becomes visible again may be an adequate workaround. See https://developer.mozilla.org/en-US/docs/Web/API/Document/visibilitychange_event

If this is a Chromium-specific issue, you could try filing a bug at https://crbug.com/.

[jan-ivar]

@simbleau are you able to reproduce this in Firefox? If not, I suggest closing this and opening an issue on chromium.

[simbleau]

Well, I can't find a way to test on Firefox, it doesn't work for me at all. I get connection rejected errors because self signed certs aren't accepted.

Do you know of a good way to test this on FF?

[wilaw]

@simbleau - if you run this simple example https://webrtc.internaut.com/wt/ on a Chrome tab, connect, send some data, than switch to another tab, come back, in my testing you can resume sending data, meaning that the underlying WebTransport connection was not closed. Do you get the same behavior?

[simbleau]

@simbleau - if you run this simple example https://webrtc.internaut.com/wt/ on a Chrome tab, connect, send some data, than switch to another tab, come back, in my testing you can resume sending data, meaning that the underlying WebTransport connection was not closed. Do you get the same behavior?

Hm, that works on both browsers for me.

The only difference I can think of is that in our implementation, we poll WebTransport consistently from WebAssembly.

Perhaps this is an issue of our own? @MOZGIII @cBournhonesque

[jan-ivar]

Well, I can't find a way to test on Firefox, it doesn't work for me at all. I get connection rejected errors because self signed certs aren't accepted.

Self-signed certs should be supported in Firefox. Please file an issue on Firefox with your symptoms.

[wilaw]

Closing as we don't believe this is an issue with the web API. Both WebSocket and WebTransport connections are tied to the Document (webpage), whose lifetime is generally understood to survive tab switching, so there should be no need to call this out explicitly in this spec. Please reopen if you still feel that a spec change is required.