Skip to content

persist() relies on the deprecated unload event #370

Description

@Huruikagi

Summary

The persist() extension currently writes the collection state to localStorage in an unload event listener:

https://github.com/mswjs/data/blob/main/src/extensions/persist.ts

window.addEventListener('unload', () => {
  localStorage.setItem(/* ... */)
})

The unload event is deprecated and is being gradually disabled in Chrome:

https://developer.chrome.com/docs/web-platform/deprecating-unload

In Chrome 150, registering this listener produces the following console error:

[Violation] Permissions policy violation: unload is not allowed in this document.

This prevents persist() from reliably saving the latest collection state when a page is closed, navigated away from, or reloaded.

Expected behavior

The latest collection state is stored reliably and restored on the next page load, as described in the persist() documentation.

Actual behavior

Persistence depends on the unload event being dispatched. When Chrome blocks the event listener, recent changes are not written to localStorage, and the next page load may restore stale or empty data.

Steps to reproduce

  1. Open an application using the persist() extension in Chrome 150.

  2. Create or update a record in the collection.

  3. Observe the following error in the browser console:

    [Violation] Permissions policy violation: unload is not allowed in this document.
    
  4. Close, reload, or navigate away from the page.

  5. Open the page again.

  6. Observe that the latest collection state was not persisted.

Environment

  • @msw/data: 1.1.7

  • Chrome: 150.0.7871.115 (Official Build) (64-bit)

  • Console error:

    [Violation] Permissions policy violation: unload is not allowed in this document.
    

Possible directions

Potential alternatives may include persisting changes when the collection is modified, or using lifecycle events such as visibilitychange or pagehide. I am not sure which approach best matches the intended semantics of the extension.

Related issue

#343 also discusses persistence and hydration behavior, but it does not appear to cover the dependency on the deprecated unload event itself.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions