13824 2011-08-18 13:07:19 +0000 If location.href is set in window.onload, firefox treats it as a redirect and removes the page from the session history. Consider specifying that. 2011-10-21 22:30:50 +0000 1 1 1 Unclassified HTML WG HTML5 spec unspecified Other other RESOLVED WORKSFORME http://www.whatwg.org/specs/web-apps/current-work/#location P3 normal --- 1 contributor ian adrianba ayg eseidel ian mike mjs public-html-admin public-html-wg-issue-tracking w3c zcorpan public-html-bugzilla oldest_to_newest 55422 0 contributor 2011-08-18 13:07:19 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/complete/history.html Multipage: http://www.whatwg.org/C#location Complete: http://www.whatwg.org/c#location Comment: If location.href is set in window.onload, firefox treats it as a redirect and removes the page from the session history. Consider specifying that. Posted from: 85.227.157.71 by simonp@opera.com User agent: Opera/9.80 (Macintosh; Intel Mac OS X 10.5.8; U; en) Presto/2.9.168 Version/11.50 55423 1 zcorpan 2011-08-18 13:09:40 +0000 Probably also if it's set before onload. 57801 2 ian 2011-10-04 20:04:20 +0000 That's relatively easy to do (just means that that navigation is done "with replacement enabled" if "something is delaying the load event"). Do other browsers do this? Do they want to? 57810 3 adrianba 2011-10-04 20:27:04 +0000 IE does not do this. We don't see a reason to change: web developers can use location.replace if they want this behaviour. 57861 4 ayg 2011-10-05 19:47:41 +0000 If the document's location is set in or before the load event, it might mess up the history if it's kept. Namely, hitting back will go to the previous page, which will immediately send you back to the current page. This is annoying, and I've seen it happen. It means the user has to hit back very quickly multiple times in succession, or else pick a page to navigate to from the back button drop-down menu (which not all users will know about of think of). It's unlikely that authors will want this to happen, and it's annoying for users. Setting location.href is the obvious way to change the URL, and few authors will even think about whether the current page will remain in the history or what implications that will have for hitting Back. So location.href should behave in the most useful way by default. If authors explicitly want to have such a transient page in the tab history for some reason, they should have to opt in by explicitly using location.assign, so that it's harder for them to shoot themselves in the foot. With the test page <!doctype html> <script>location.href = 'http://www.google.com/'</script> I find that IE9 preserves the intermediate page in the history, but Firefox 8.0a2, Chrome 15 dev, and Opera 11.50 do not. In IE9, I do indeed have to hit back very rapidly or use the drop-down menu to successfully go back. With <!doctype html> <body onload="location.href = 'http://www.google.com/'"> I seem to get the same results in all browsers. So it seems like we should definitely do this. 57895 5 zcorpan 2011-10-06 07:59:55 +0000 I agree with Aryeh. Lots of pages to "redirects" by setting location.href. Breaking the back button is a bad user experience. 58665 6 ian 2011-10-21 22:30:50 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: no spec change Rationale: Turns out the spec already says this, actually.