Determine interaction with back forward cache

[ricea]

We need to specify the behaviour when the page is navigated away and the document is placed in the browser's back forward cache. Also what happens if/when the page is restored from the cache.

[rakina]

Thanks for filing this! The BFCache team and the Web Transport team discussed about this earlier but haven't reached any conclusions on what to do with existing WebTransport connections when the page is put into BFCache.

As it is currently specced, it will go through the unloading steps which will fail existing connections (CMIIW). We might want to change this to be more useful/powerful if the page enters BFCache (loses full activity), e.g. maybe keep the connection in some form.

In case it might be useful, here's a link to the TAG design principles PR: w3ctag/design-principles#317
Also we have a BFCache meta-bug in case you need examples of past spec issues: whatwg/html#5880

(cc @fergald)

[jan-ivar]

I think it's desirable and POLA to close connections when navigating away from a page. The BFCache is a user agent optimization that some browsers do, but we should consider that most pages that go on it are never to be heard from again.

The current behavior matches webrtc and websocket which seems right to me.

Also what happens if/when the page is restored from the cache.

It stays closed?

[fergald]

Also what happens if/when the page is restored from the cache.

It stays closed?

Ideally the close event was delivered when the page comes back out of BFCache. My understanding is that the close event is not delivered when the connections are closed due to navigating away, so there would be no change for the never-restored case.

[jan-ivar]

Meeting

• Agreement to leave session in a terminal state, but reject promises only on revival from BFCache.

[rakina]

Is there a spec update needed for this? We can also write a WPT for this now that BFCache WPT support had landed (see also: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/html/browsers/browsing-the-web/back-forward-cache/README.md)

[jesup]

Correct me if I'm wrong, but the current state of the spec leaves a document that's made a trip through the bfcache in an invalid state: FAILED, connection dropped, but cleanup() hasn't been run: ready and closed may not be resolved (or rejected), any active streams have not be errored, etc.
So, we need to do something since that's not good. We need some PR to do something about this (can we just run cleanup() in document unloading steps?)
What does Chrome do currently?

[rakina]

Just want to chime in that running cleanup() in "[unloading document cleanup steps]"(https://html.spec.whatwg.org/multipage/document-lifecycle.html#unloading-document-cleanup-steps) is probably a good thing to do. Not sure if it's needed, but if there are things that needs to be done on navigation back to the page (BFCache restore) you can also listen to that through adding a step in "reactivate a document"

[jesup]

FYI, Mozilla is going to block pages with CONNECTING/CONNECTED status from the bfcache for now, until this is resolved. Testing shows us that Chrome appears to be blocking it as well (@ricea ?) including in a case we allow (shared worker with a closed or failed WebTransport).

[fergald]

@jesup Chrome does not allow pages with shared workers into BFCache. A page with a dedicated worker and an open WT connection would be blocked. If think our current impl is that if the connection object exists, we block, we don't examine the state. This is supposed to be a temporary situation until the correct behaviour is available.

[ricea]

I see a bunch of options:

1. Ban pages using WebTransport from the bfcache. This is essentially what Chromium and Mozilla have implemented.
2. Allow pages using WebTransport to enter the bfcache, but close the connection when navigating away. The various promises will resolve if/when the page is navigated back to.
3. Allow the connection to stay open when the page enters the bfcache, but evict if any data arrives.
4. Allow the connection to stay open when the page enters the bfcache, and buffer incoming data. Replay the buffered data when navigating back to the page. If the buffered data exceeds N MB then evict the page from the bfcache.

There are probably other options I haven't considered.

1. is the status quo. It's fine if WebTransport remains a niche thing, but if we want it to become ubiquitous like WebSockets then it's a blocker for adoption.
2. This is my preferred option. It should be relatively easy to standardise as I think "queue a task to the network task source that resolves the promise" just works. I don't know how to implement it. The risk is that pages won't have implemented reconnection logic and will just do nothing when you navigate back to them. But that can be solved with developer education.
3. Most of the time this is going to be equivalent to the status quo, but much less efficient.
4. I don't like this because pages will come back from the bfcache with buffers full of stale data. The server will have no idea anything has happened. Backpressure won't work meaningfully. Users will have background network activity they are unaware of. Plus the implementation will require twice as many queues as we already have.

[jan-ivar]

Thanks for exploring the options!

1. Ban pages using WebTransport from the bfcache. This is essentially what Chromium and Mozilla have implemented.

1. is the status quo. It's fine if WebTransport remains a niche thing, but if we want it to become ubiquitous like WebSockets then it's a blocker for adoption.

How is doing the same as WebSocket an obstacle to becoming ubiquitous like WebSockets?

Pages using WebSocket seem already banned from the bfcache:

...and [sic]:

2. ... The risk is that pages won't have implemented reconnection logic and will just do nothing when you navigate back to them. But that can be solved with developer education.

Relying on apps to write special code to handle BFCache seems unrealistic, but perhaps with a sufficiently motivating use case that might change. What are some compelling use cases?

[fergald]

@jan-ivar
It's an obstacle because it would force devs to choose between performance (BFCache) and use of this API. Chrome measures WebSockets blocking 2-3% of all history navigations from using BFCache. This hurts users and sites. We don't want to add another (growing) source of blockage if we can help it.

What do you mean by "what are some compelling use cases?"? Use cases for what?

Shoudln't all users of the API should be handling unexpected closures of the WebTransport anyway, just to deal with "normal" failures? BFCache would just be another source of failures.

[jan-ivar]

Thanks for explaining the rationale. It makes sense to learn from experience with WebSocket. But what's the lesson?

Shoudln't all users of the API should be handling unexpected closures of the WebTransport anyway, just to deal with "normal" failures?

Same question to WebSocket. E.g. what's blocking whatwg/html#1931 from fixing those 2-3%? What makes us think apps would use WebTransport more responsibly than they use WebSocket today?

I fear the lesson might be that what apps "should" do is different from what they will do. What I meant with "compelling use cases" is what would compel individual apps to care about navigation performance over convenience, and what sort of apps might they be?

The benefit is not lost on me, but we seem to be running out of time to correct this. Unless whatwg/html#1931 harbors some solution I missed, the only incentive I see for apps to handle connection failure from navigation, is for already shipping implementations to require it asap to not break them.

[fergald]

I believe the same argument applied to WebSock but my understanding is that WebSocket's usage was large enough that it was considered too disruptive.

The best time to do make WebTransport compatible with BFCache (as with all APIs) was before launch, the second best time is now, assuming usage is only going to grow.

What I meant with "compelling use cases" is what would compel individual apps to care about navigation performance over convenience, and what sort of apps might they be?

I don't think that's the right question. The offer in 2 is not "add a close handler and we will give you BFCache", it's "we're giving the user BFCache, add a close handler or your app will be broken (more than it already is)".

For 2, the question is whether we (browsers) can justify any breakage that occurs. Arguably any app that breaks with 2 was already broken. Is there a common use case where not handling closure is reasonable? Playing around with https://webtransport.day/, any time I drop off the network, the connection closes pretty quickly. So it does seem like any "serious" apps would already handle closure.

It's actually surprising how sensitive it is. I expected that it would survive me going offline for a few seconds. Not sure if that's intrinsic to the feature or just Chrome's implementation.

[jan-ivar]

"we're giving the user BFCache, add a close handler or your app will be broken (more than it already is)".

Is there a precedent showing this worked, or would WebTransport be first?

AFAIK BFCache was/is an optimization some browsers did, with the onus on UAs to not break applications or require their participation to not break. Specs seem to mention BFCache a lot more these days, and more browsers do it, which is encouraging, but is there an explainer doc with current thoughts? I found whatwg/html#5880 but no overview explanation. I'm wondering when this shift happened or if it has.

[jan-ivar]

Playing around with https://webtransport.day/, any time I drop off the network, the connection closes pretty quickly. ... I expected that it would survive me going offline for a few seconds. Not sure if that's intrinsic to the feature or just Chrome's implementation.

In both Chrome and Firefox it fails for me about ~10 seconds after I disconnect WiFI. If I reconnect before that time then the connection survives. WebTransport is fairly low-level, so I'm not surprised. @jesup may know more.

[fergald]

AFAIK BFCache was/is an optimization some browsers did, with the onus on UAs to not break applications or require their participation to not break. Specs seem to mention BFCache a lot more these days, and more browsers do it, which is encouraging, but is there an explainer doc with current thoughts? I found whatwg/html#5880 but no overview explanation. I'm wondering when this shift happened or if it has.

Mozilla and Safari have had it for years. Chome has it recently. Safari is pretty aggressive and caches in some cases where Mozilla and Chrome don't, e.g. on desktop unload handlers will block Chrome and Mozilla but not Safari (on mobile, unload is already quite unreliable so we were OK with skipping them if it makes the page BFCachable). It will also just drop message on a BroadcastChannel for pages that are in BFCache (I don't think this is the right approach, it's being discussed here, just pointing out that Safari has pushed this quite far).

The TAG design principles were updated in the last year to include a section on making sure your feature works with BFCache (and prerendering).

In the last 2 years, Chrome (mostly @rakina) has done a bunch of work to make BFCache better represented in Web Platform docs and to fix up problems in standards. We are trying to make it impossible to add a feature without being explicit BFCache. Safari and Mozlla are quite on-board with this effort.