New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTML 5 History - replaceState using incorrect path when a base tag is set #1159

roblund opened this Issue Sep 3, 2013 · 2 comments


None yet
3 participants
Copy link

roblund commented Sep 3, 2013

I found this issue while using the YUI history-html5 module, and I've written up an issue over in the Chromium bug tracker ( The example I put together on the Chromium bug tracker used only native history controls, but I wanted to show an example of how you can run into the same thing when using YUI. I created a Gist ( containing a simple page. You should be able to reproduce the issue by using the following steps.

  1. Save the Gist to a file (start up something like a python simplehttpserver to serve the page)
  2. Load the test page in Chrome
  3. On the first load, we will drop into the 'if' and run HistoryHTML5.add() which should append our query string to the URL and add our history state to the stack.
  4. Click 'some link' and go to the test2 page (which is just blank page with no JS)
  5. Click Back in the browser
  6. Verify you are sent back to test.html.
  7. Click 'some link' again and go to the test2 page.
  8. Click Back in the browser
  9. You will be sent to test3.html which is the href in your base tag.

YUI is calling replaceState when the page is loaded after clicking back and a 'null' is sent in as the third parameter, which corresponds to URL. You can see this on line 107 of Chrome/Webkit is then incorrectly then taking the href from the base tag and adding that to the history stack instead of using the current url (which is what Firefox and Internet Explorer do).

The reason this is relevant to YUI is that I believe you could potentially workaround this bug in Chrome/Webkit by changing the 'null' on line 107 of to instead be 'document.URL'. In my limited testing this seems to avoid the Chrome/Webkit issue completely, because you are explicitly setting the url that is sent into replaceState.

If there's anything that doesn't make sense, please let me know and I'll be happy to clarify.


This comment has been minimized.

Copy link

rgrove commented Sep 7, 2013

@roblund Thanks for the detailed report and the simple repro case!

I think your proposed solution sounds reasonable, but I'll want to test it to be sure. Do you feel like sending a pull request? If not, I'll dig into this as soon as I have time.

@ghost ghost assigned rgrove Sep 7, 2013


This comment has been minimized.

Copy link

roblund commented Sep 7, 2013

Sure, I'll send over a pull request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment