Bug 301702
| Summary: | [bfcache] Pages with open WebSocket connections should not be cached | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Simon Pena <spena> |
| Component: | DOM | Assignee: | Simon Pena <spena> |
| Status: | RESOLVED INVALID | ||
| Severity: | Normal | CC: | annevk, ap, cdumez, pgorszkowski, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Simon Pena
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
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
<rdar://problem/164176275>
Simon Pena
(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
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?