Skip to content

Proposal: Unblock bfcache for active WebSockets by disconnecting on entry #12085

@llannasatoll

Description

@llannasatoll

What is the issue with the HTML Standard?

Problem

The interaction between active WebSockets and bfcache is currently undefined in the HTML Standard, leading to divergent browser behaviors as observed in web-platform-tests:

  • Chrome & Mozilla: Active WebSockets prevent bfcache eligibility (the page is evicted).
  • WebKit: The page remains eligible, as the User Agent automatically closes the connection upon entry.

Proposal

We propose that user agents should automatically disconnect active WebSockets when a page enters bfcache. This allows the page to be cached while avoiding the problems that come from holding open connections - resource usage, privacy.

Developer Experience & Detection

Developers can rely on the standard onclose event to handle the disconnection. When a page is restored from bfcache, the onclose event will be invoked, allowing applications to trigger their existing reconnection logic.

Any application that fails to handle this disconnection is likely already broken in common scenarios, such as device suspension or network switching. As these situations already require reconnection strategies, this change aligns with existing behavior and should not introduce new breakage.

Discussion Needed

We seek to standardize the disconnection behavior. We are looking for feedback on the following:

  • Error Handling:
    • The user agent should fire an onerror event before onclose, with event.wasClean set to false.
    • Apps that don't handle errors are likely already broken in common scenarios, suggesting that dispatching an error might be the appropriate behavior.
  • Status Code:
    • Client-side: The listener receives code 1006 (Abnormal Closure).
    • Server-side: The user agent sends a Close frame with code 1001.

The goal is to avoid situations where existing clients simply accept the closure as a server-initiated closure and do not attempt to reconnect. We welcome feedback on which behavior is most compatible with existing reconnection strategies.

cc: @pgorszkowski-igalia @annevk @zcorpan @ricea @fergald

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions