RESOLVED INVALID301702
[bfcache] Pages with open WebSocket connections should not be cached
https://bugs.webkit.org/show_bug.cgi?id=301702
Summary [bfcache] Pages with open WebSocket connections should not be cached
Attachments
Alexey Proskuryakov
Comment 1 2025-10-30 13:36:05 PDT
This was an intentional change (bug 143505). Could you please elaborate on why they shouldn't? The connection can always be reestablished, and webpages need to support interruptions to network connections anyway, that's a very normal thing to happen.
Radar WebKit Bug Importer
Comment 2 2025-11-06 09:00:16 PST
Simon Pena
Comment 3 2025-11-06 09:22:21 PST
(In reply to Alexey Proskuryakov from comment #1) > This was an intentional change (bug 143505). Could you please elaborate on > why they shouldn't? The connection can always be reestablished, and webpages > need to support interruptions to network connections anyway, that's a very > normal thing to happen. Hi, @ap, sorry I missed your reply. I see that the implementation in https://bugs.webkit.org/show_bug.cgi?id=143505 closes the connection, then queues a "closed" event for the page to handle when (if) restored, then caches the page. My "should not" be cached was based on the WPT test expectations, and mentions such as https://html.spec.whatwg.org/multipage/nav-history-apis.html#the-pagetransitionevent-interface, https://html.spec.whatwg.org/#unloading-document-cleanup-steps or https://developer.mozilla.org/en-US/docs/Web/API/Performance_API/Monitoring_bfcache_blocking_reasons#websocket. These resources all point to active WebSocket objects as potential reasons to render a page unsalvageable. I am unclear whether these resources work more as specifications or recommendations, and whether WebKit's current behaviour is acceptable -- and we might want to change the WPT test expectations -- or not acceptable -- and we might want to change WebKit's behaviour and push pages to use the page lifecycle events
Simon Pena
Comment 4 2025-11-27 04:49:16 PST
Since this was intentional, this bug is invalid. I will raise another one, updating the test expectations so that it is explicit that we are "failing" from the point of view of WPT. Afterwards we probably need to get the spec updated?
Note You need to log in before you can comment on or make changes to this bug.