mdn / mdn/browser-compat-data

api.History.replaceState - stated as supported but actually not compliant (with the spec) on Firefox

Open
#15,261 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

browser:firefox data:api
Dominant language
JSON
Stars
5.8k
Forks
2.6k
Avg merge
1d 21h
Merged PRs (30d)
186

Description

Firefox x86-64 97.0 on Windows 10 here.

What information was incorrect, unhelpful, or incomplete?

The article on History.replaceState seems to communicate with the compatibility table there at the end, that the method is supported on Firefox. However, evidently this is only true to an extent -- Firefox does not support saving Error objects as part of the state specified with the first parameter. Since this lack of support is deviation from the standard behaviour as specified by HTML 5 (starting at point 17 in the list of steps, specifically), I believe this should be communicated with an "asterisk" (per MDN visual conventions) that clarifies there is said deviation from the standard.

What did you expect to see?

I expected to see lack of support for serializing Error objects, be stated explicitly in the article, since it deviates from specified behaviour for the method. The statement should probably also be added for related methods like pushState.

Did you test this? If so, how?

Yes, I evaluated history.replaceState(new Error("Test message"), undefined) which throws a DOMException with the message "The object could not be cloned".

MDN page report details

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the compatibility data for api.History.replaceState and compare the related pushState entry. Confirm how Firefox handles Error objects in the state argument, then record the limitation using the repository’s existing compatibility-data conventions; done means the deviation is explicit for the affected methods.

Written by the indexing model from the issue text.

Assessment

Tech stack
html, javascript
Domain
api, documentation, web-dev
Issue type
Documentation
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.