history.replaceState 不适用于 firefox v56+
history.replaceState not working for firefox v56+
在我的应用程序中，为了在 URL 中隐藏一些信息，我使用以下代码。
history.replaceState ({}, "", "bar.html");
它适用于所有浏览器除了 firefox 最新版本 (v56+)
在 Firefox 中，如果我按 F5，它将返回到之前的 URL，我已经用上面的代码替换了它。
任何帮助将不胜感激。
Video Example 1 and Video Example 2 解释如何重现错误。
Conditions:
- Mozilla Firefox version only
56+
- Single Page Application
- For routing uses
history.replaceState, all parameters not null
Steps:
- Login & redirect to main page base
URL
- Navigate on any application tab & replace URL parameters
- Press
F5, cmd + r or click Refresh button
- Ups!.. Again open main page with base
URL (but in other browsers we see the selected tab and the correct URL)
从 url.
中删除查询字符串时会遇到相同的行为
可能是以下行为引起的（我引用Vadim Goncharov）
The main problem is that after using history.replaceState and then clicking cmd+r/f5 we will see that browser sends replaced (correct) url to server, but shows incorrect url both in location.search and browser url bar. And this behaviour continues (if click to "cmd+r/f5") until we click "enter" on browser url bar.
第一个 解决方法 发布自 Felix Lee
Before calling history.replaceState, do
location.hash = location.hash;
Setting hash to itself has no effect, but makes the bug go away.
此解决方法并不理想，mtomalley 添加了 第二个解决方法
The browser is requesting a different URL than what is shown in the location bar....
Additionally, the workaround isn't ideal because if the URL doesn't already have a hash, location.hash = location.hash adds one, calls popstate, and adds a history entry.
An alternate workaround that is much less simple:
- Use whatever means available to your backend technology to expose the request
URI on the client
- On page load (before any client routing code), check the
URI against window.location
- If they're different, use
replaceState to fix it.
The location will briefly show the incorrect URL on any reload, but at least it'll be fixed and routing can work as expected...
提出的第三种解决方法
window.addEventListener('unload', function(event) { location.replace(location) });
This way the state of the js location is flushed to FFs location in cases of refreshes and tab closes (which by the way have the same issue when reopened with e.g. ⌘+⇧+t).
来自 Mathis 的上述解决方法存在以下问题（我引用 jimmyhmiller）
Next.js tried using the workaround that Mathis mentioned above and it caused some bad issues for them. Details here: https://github.com/zeit/next.js/pull/6896
上述 解决方法 遇到了一个新错误，在问题 #6882
中进行了解释
when landing on a page that contains query parameters, the browser becomes "locked" to that page and programmatically or manually navigating to a different same-domain page insta-redirects back to the original. note that this does not start happening until a query parameter is involved in the url, totally bizarre
我还列出了 other mozilla related issues with history.replaceState。
我随时可以对这篇文章进行进一步分析、研究和改进，我很高兴收到您的反馈。
在我的应用程序中，为了在 URL 中隐藏一些信息，我使用以下代码。
history.replaceState ({}, "", "bar.html");
它适用于所有浏览器除了 firefox 最新版本 (v56+)
在 Firefox 中，如果我按 F5，它将返回到之前的 URL，我已经用上面的代码替换了它。
任何帮助将不胜感激。
Video Example 1 and Video Example 2 解释如何重现错误。
Conditions:
- Mozilla Firefox version only
56+- Single Page Application
- For routing uses
history.replaceState, all parameters not nullSteps:
- Login & redirect to main page base
URL- Navigate on any application tab & replace URL parameters
- Press
F5,cmd + ror clickRefreshbutton- Ups!.. Again open main page with base
URL(but in other browsers we see the selected tab and the correct URL)
从 url.
中删除查询字符串时会遇到相同的行为可能是以下行为引起的（我引用Vadim Goncharov）
The main problem is that after using
history.replaceStateand then clickingcmd+r/f5we will see that browser sends replaced (correct)urlto server, but shows incorrect url both inlocation.searchand browser url bar. And this behaviour continues (if click to "cmd+r/f5") until we click "enter" on browser url bar.
第一个 解决方法 发布自 Felix Lee
Before calling
history.replaceState, dolocation.hash = location.hash;Setting
hashto itself has no effect, but makes the bug go away.
此解决方法并不理想，mtomalley 添加了 第二个解决方法
提出的第三种解决方法The browser is requesting a different URL than what is shown in the location bar....
Additionally, the workaround isn't ideal because if the
URLdoesn't already have ahash,location.hash = location.hashadds one, callspopstate, and adds a history entry.An alternate workaround that is much less simple:
- Use whatever means available to your backend technology to expose the request
URIon the client- On page load (before any client routing code), check the
URIagainstwindow.location- If they're different, use
replaceStateto fix it.The location will briefly show the incorrect URL on any reload, but at least it'll be fixed and routing can work as expected...
window.addEventListener('unload', function(event) { location.replace(location) });
This way the state of the js location is flushed to FFs location in cases of refreshes and tab closes (which by the way have the same issue when reopened with e.g. ⌘+⇧+t).
来自 Mathis 的上述解决方法存在以下问题（我引用 jimmyhmiller）
Next.js tried using the workaround that Mathis mentioned above and it caused some bad issues for them. Details here: https://github.com/zeit/next.js/pull/6896
上述 解决方法 遇到了一个新错误，在问题 #6882
中进行了解释when landing on a page that contains query parameters, the browser becomes "locked" to that page and programmatically or manually navigating to a different same-domain page insta-redirects back to the original. note that this does not start happening until a query parameter is involved in the url, totally bizarre
我还列出了 other mozilla related issues with history.replaceState。
我随时可以对这篇文章进行进一步分析、研究和改进，我很高兴收到您的反馈。