WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED INVALID
301702
[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
Simon Pena
Reported
2025-10-30 09:59:41 PDT
Tests:
https://wpt.fyi/results/websockets/back-forward-cache-with-open-websocket-connection.window.html?label=master&label=experimental&aligned
https://wpt.fyi/results/websockets/back-forward-cache-with-closed-websocket-connection.window.html?label=master&label=experimental&aligned
Attachments
Add attachment
proposed patch, testcase, etc.
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
<
rdar://problem/164176275
>
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.
Top of Page
Format For Printing
XML
Clone This Bug