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

[roblund]

I found this issue while using the YUI history-html5 module, and I've written up an issue over in the Chromium bug tracker (https://code.google.com/p/chromium/issues/detail?id=279278). 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 (https://gist.github.com/roblund/6430494) 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 https://github.com/yui/yui3/blob/master/src/history/js/history-html5.js. 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 https://github.com/yui/yui3/blob/master/src/history/js/history-html5.js 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.

[rgrove]

@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.

[roblund]

Sure, I'll send over a pull request.