Is it still necessary reading hash from href now? #726
Labels
Comments
|
It may have changed in recent versions of Firefox, but we still support Firefox >= 43. We can remove that code and bump our supported Firefox version, but it will require a major release. |
|
Bumping browsers up in that list should definetly be on the agenda for the next major version. IE 10 isn't even supported by Microsoft anymore. And the current firefox long term support is version 60. |
mjackson
added a commit
that referenced
this issue
Nov 5, 2019
New features: - Remove legacy browser support (pre pushState) - Add state to hash history - Use custom window when creating history objects - Better history.block API (wip) - Fix location.pathname encoding issues - About 50% smaller - No dependencies Removed features: - Removes basename support - Removes getUserConfirmation - Removes keyLength - Removes hashType - Removes relative pathname support in hash + memory histories Still TBD: - Missing pathname support in push/replace Fixes #624 Fixes #704 Fixes #723 Fixes #726
Merged
|
Heads up: we are no longer doing this in the v5 beta released earlier today. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In the
createHashHistory.js, there is a comment innergetHashPath()But in the next function
pushHashPath, it set hash directly.I found the problem of pre-dcode location.hash happened about 6 years ago, and the recent version of firefox is working ok.
The text was updated successfully, but these errors were encountered: