This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13824 - 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.
Summary: If location.href is set in window.onload, firefox treats it as a redirect and...
Status: RESOLVED WORKSFORME
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-18 13:07 UTC by contributor
Modified: 2011-10-21 22:30 UTC (History)
10 users (show)

See Also:

Attachments

Description contributor 2011-08-18 13:07:19 UTC 
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
Comment 1 Simon Pieters 2011-08-18 13:09:40 UTC 
Probably also if it's set before onload.
Comment 2 Ian 'Hixie' Hickson 2011-10-04 20:04:20 UTC 
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?
Comment 3 Adrian Bateman [MSFT] 2011-10-04 20:27:04 UTC 
IE does not do this. We don't see a reason to change: web developers can use location.replace if they want this behaviour.
Comment 4 Aryeh Gregor 2011-10-05 19:47:41 UTC 
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.
Comment 5 Simon Pieters 2011-10-06 07:59:55 UTC 
I agree with Aryeh. Lots of pages to "redirects" by setting location.href. Breaking the back button is a bad user experience.
Comment 6 Ian 'Hixie' Hickson 2011-10-21 22:30:50 UTC 
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.