views:

157

answers:

1

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:

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 common 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!

A: 

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 common 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).

Nickolay