2

With window.history.pushState it is possible to push a state to the browser's history.

Example:

<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body>
<input type="button" value="foo" onclick="setHistory('foo');">
<input type="button" value="bar" onclick="setHistory('bar');">
<script>
function setHistory(string) {
    document.title = string;
    window.history.pushState(
            'object or string', 
            '', 
            string+'.html'
        );
}
</script>
</body>
</html>

After clicking on the foo and bar button the responding entries will appear in the browser's history. This works in Firefox, Chrome, and Safari. However, not in IE (>10) and Edge even though they officially support it. Is there a way to achieve this?

The answers at Does Internet Explorer support pushState and replaceState? are not useful since they explain the problem only with IE<10 where pushState is not supported.

Edit

Apart from not updating the history, pushState seems works otherwise fine in IE and Edge, i.e. updates the URL, can navigate back and forth, the "back and forth drop down list" is updated accordingly.

Edit 2

I just read https://msdn.microsoft.com/en-us/library/ms535864(v=vs.85).aspx. Under "Remarks" it states

"For security reasons, the history object does not expose the actual URLs in the browser history."

So maybe the part of pushState I am after just isn't supported in IE and Edge?

Community
  • 1
  • 1
Daniel
  • 2,642
  • 3
  • 23
  • 48
  • Here's an example using replaceState with a use case: http://blog.scoutapp.com/articles/2010/12/07/manipulating-browser-history-with-javascript-pushstate-replacestate – Rob Parsons Jan 30 '17 at 00:43
  • @RobParsons Thanks. But is there an answer to the problem with IE/Edge? – Daniel Jan 30 '17 at 07:28
  • I hope you don't mind my mentioning: http://www.w3.org/TR/html5/browsers.html#dom-history-pushstate "6. Set the document's address to new URL. Note: Since this is neither a navigation of the browsing context nor a history traversal..." – user4749485 Jan 31 '17 at 02:50
  • @user4749485 Thanks. Of course I don't mind. But it would be even more helpful if you could explain what that means and implies for the question. I know that `pushState` does not cause a reload of the page. But it should still be added to the browsing history, or? – Daniel Jan 31 '17 at 09:00
  • W3C says pushstate is not a navigation. Since no navigation occurs, why would it be recorded into the user History dialog? – user4749485 Jan 31 '17 at 13:13
  • There was a similar question on MS-Connect regarding if a pushstate url should even be marked as "visited". – user4749485 Jan 31 '17 at 13:18
  • @user4749485 I guess that depends on what navigation means. According to W3C navigation implies a number of things: https://www.w3.org/TR/html5/browsers.html#navigate. Why do you think if something is not a navigation in this sense it should not be recorded? I don't see it. – Daniel Jan 31 '17 at 14:01
  • We can pushstate any free-form gibberish we want to the addressbar. In fact, the spec encourages us to do that, if the user will benefit from having those milestones/states to back- and forward-button to, during that session. But those breadcrumbs on the addressbar we are pushing are not necessarily real urls that can be navigated to. You wouldn't want to flood the user's History dialog with unusable breadcrumbs, would you? – user4749485 Jan 31 '17 at 15:02
  • @user4749485 Of course I don't want to flood the user's history with unusable stuff. But I want to add to the history usable stuff, like when he saved on the page or so. That can be really helpful. Flooding the user's history can already be accomplished by opening new pages. So I don't see what extra protection disallowing the adding to the history achieves. – Daniel Jan 31 '17 at 15:11
  • An example is jsFiddle: if you save a fiddle anonymously you can find it in your history in both Firefox and Chrome. However, in IE/Edge you have to remember to bookmark it otherwise it gets lost. – Daniel Jan 31 '17 at 15:14

2 Answers2

1

IE10 and above do support pushState and replaceState and your example code works in both.

However you might be triggering compatibility mode and rendering using a lower version of IE. (Again your sample code does so and renders using IE7 which doesn't support history api)

Compatibility mode

You can check this by pressing F12 to bring up the developer tools and seeing what version of IE is listed on the right of the black bar.

To stop it doing that, add this to your <head>:

<meta http-equiv="X-UA-Compatible" content="IE=edge" />

enter image description here

JamesT
  • 2,724
  • 21
  • 29
  • Thanks. However, on my machine IE 11 is in Edge mode by default. Also `pushState` kind of works in that the url changes. But no history item is created. (Adding the compatibility mode does not change anything.) Does your browser add the pages to the history? (I've also edited my answer to make misunderstanding of what is happening less likely.) – Daniel Jan 27 '17 at 14:50
  • I get foo and bar history entries in IE11 and I can navigate forward and back through them – JamesT Jan 27 '17 at 15:04
  • That is surprising. How do you look at the history? By clicking on the star symbol? I can only navigate back and forth (and get the respective entries in the drop down menu next to the back and forth buttons) but get no entries in IE11 in the history. – Daniel Jan 27 '17 at 15:23
  • IE's Tracking Protection lists, Send Do Not Track header setting and InPrivate browsing and Clear History when browser is closed settings can have an impact on which domains appear in the IE History data-base when visited. Tools>Internet Options>Advanced tab, check "Always record developer console messages" to receive dev tool console messages about blocked content and security warnings. Use the network tab to inspect the navigation request headers. – Rob Parsons Jan 28 '17 at 21:33
  • @RobParsons I don't understand fully how this relates to the question. However, I activated the recording and nothing is send to the network tab (IE 11). – Daniel Jan 30 '17 at 07:32
0

IE/Edge seems not to play along for some reason - not surprising I guess.

The only way to change the history seems to be an added reload of the page via window.location.reload(), history.go(0), or window.location.href=window.location.href.

https://codepen.io/pen seems to do it that way.

This is a bit annoying since one would also like to keep the current state of the website. Maybe one could check whether the users browser is IE and only then do annoying reload. Other browsers seem to play along just fine.

Daniel
  • 2,642
  • 3
  • 23
  • 48