There is an open issue on Bugzilla
.
Video Example 1 and Video Example 2 explain how to reproduce the bug.
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)
The same behaviour is experienced when removing query strings from the url.
It could be caused from the following behaviour (I quote 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.
First Workaround posted from Felix Lee
Before calling history.replaceState
, do
location.hash = location.hash;
Setting hash
to itself has no effect, but makes the bug go away.
This workaround is not ideal and mtomalley adds a second Workaround
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...
Third Workaround proposed from Mathis Wiehl
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).
The above workaround from Mathis has the following issue (I quote 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
A new bug was experienced with the above workaround, explained in the issue #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
I also include a list of other mozilla related issues with history.replaceState.
I keep myself available for further analysis, research, improvements to this posts and I am happy to receive your feedback.