I just came across some odd behavior in Firefox 3.6/Mac. I suspect that it's general Firefox behavior, though.

I created two dead-simple test pages that change the window.location.href property to navigate to new URL:

• .html
• .html

If you try the following with either file:

• Open a new/blank browser tab.
• Paste the URL and hit "Enter".

You'll notice one difference between the two: using the first link, the browser's "Back" button is disabled; using the second, it's enabled and works as I'd expect it to.

The only difference between the two scripts is that the latter sets a one-second timeout before changing window.location.href.

I don't know why this happens, and I'm trying to achieve the behavior of the second script (where the "Back" button continues to work as expected) without causing any delay for the user.

My best guess is that maybe Firefox treats an immediate "redirect" by setting window.location.href the same as using the window.location.replace() method, since I think it's mon for developers to use the former when they meant to use the latter. Maybe using setTimeout, since that causes the code to run asynchronously, defeats this behavior. Could that be the case?

I haven't experimented with the minimum value for setTimeout to achieve the desired effect, but I'll do that now. I would like to figure out why this happens exactly, though.

Thanks!

I just came across some odd behavior in Firefox 3.6/Mac. I suspect that it's general Firefox behavior, though.

I created two dead-simple test pages that change the window.location.href property to navigate to new URL:

• http://troy.onespot./static/stack_overflow/redirect.html
• http://troy.onespot./static/stack_overflow/redirect_timeout.html

If you try the following with either file:

• Open a new/blank browser tab.
• Paste the URL and hit "Enter".

You'll notice one difference between the two: using the first link, the browser's "Back" button is disabled; using the second, it's enabled and works as I'd expect it to.

The only difference between the two scripts is that the latter sets a one-second timeout before changing window.location.href.

I don't know why this happens, and I'm trying to achieve the behavior of the second script (where the "Back" button continues to work as expected) without causing any delay for the user.

My best guess is that maybe Firefox treats an immediate "redirect" by setting window.location.href the same as using the window.location.replace() method, since I think it's mon for developers to use the former when they meant to use the latter. Maybe using setTimeout, since that causes the code to run asynchronously, defeats this behavior. Could that be the case?

I haven't experimented with the minimum value for setTimeout to achieve the desired effect, but I'll do that now. I would like to figure out why this happens exactly, though.

Thanks!

• javascript
• firefox
• http-redirect
• settimeout
• location-href

• The first works perfectly for me: hit the back button and e back to this page. For the second, one back shows a blank page, second back es back here. If I open in a new tab, the first works as expected, no back available. The second goes back to a blank page. These are all the exact behaviors I would expect from your description. – Skip Head Commented Sep 17, 2010 at 0:32
• 2 @Skip Head - why? why would simply setting a timeout change the behavior? – sje397 Commented Sep 17, 2010 at 0:35
• 1 Tested some more browsers for you: Happens on Chrome on Linux/Mac and Opera for Mac. Doesn't happen on Safari for Mac or Firefox for Linux. – Robert Commented Sep 17, 2010 at 0:52
• @Skip Head: As I understand it, the behavior of changing window.location.href should be to navigate to the specified URL, and then the "Back" button should take you back to the page that redirected you (thus redirecting you again). It sounds like you're seeing exactly the same behavior as I am, which is that using "Back" skips the redirect page, thus effectively working exactly like window.location.replace(), which is incorrect. – Bungle Commented Sep 17, 2010 at 0:58
• Thanks, Robert! That's good to know - and suggests that this is a browser-specific (and apparently platform-specific) quirk of some kind. I'll do some more Googling to see if I can find any leads. – Bungle Commented Sep 17, 2010 at 1:04

2 Answers 2

You are right in assuming that setting location.href while a page is loading is treated as a replace. There are in fact two separate behaviours.

The first is that setting location.href from script running as the result of parsing a tag is always interpreted as a replace. This was implemented to mirror Netscape 4 behaviour and subsequently tweaked.

The second is that any new document loaded as the result of an onload handler is also always interpreted as a replace. This was implemented and also tweaked.

But I'm curious as to why you are so keen to do this, as means that users would have to use the Back drop-down menu to go to the page before your page. (Going back one page would be no use if it kept on redirecting them to the current page.)

My best guess is that maybe Firefox treats an immediate "redirect" by setting window.location.href the same as using the window.location.replace() method, since I think it's mon for developers to use the former when they meant to use the latter. Maybe using setTimeout, since that causes the code to run asynchronously, defeats this behavior. Could that be the case?

I've been told your guess is correct, but now that I look, there's doesn't appear to be any mention of this requirement in the HTML5 spec (linking to the most relevant page, since it's hard to link to the absence of requirement).