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

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13824

--- Comment #4 from Aryeh Gregor <ayg@aryeh.name> 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.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 5 October 2011 19:47:44 UTC