JavaScript 重定向 (location.href) 会破坏“后退”按钮，除非使用 setTimeout()
我刚刚在 Firefox 3.6/Mac 中遇到了一些奇怪的行为。不过，我怀疑这是 Firefox 的普遍行为。
我创建了两个极其简单的测试页面，它们更改 window.location.href 属性以导航到新 URL：
- http://troy.onespot.com/static/stack_overflow/redirect.html
- http://troy.onespot.com/static/stack_overflow/redirect_timeout.html
如果您对任一文件尝试以下操作：
- 打开一个新的/空白的浏览器选项卡。
- 粘贴 URL 并按“Enter”。
您会注意到两者之间的一个区别：使用第一个链接时，浏览器的“后退”按钮被禁用；使用第二个，它已启用并按我的预期工作。
这两个脚本之间的唯一区别是后者在更改 window.location.href 之前设置了一秒超时。
我不知道为什么会发生这种情况，我正在尝试实现第二个脚本的行为（其中“后退”按钮继续按预期工作），而不会给用户造成任何延迟。
我最好的猜测是，也许 Firefox 通过设置 window.location.href 来处理立即“重定向”，就像使用 window.location.replace() 方法一样，因为我我认为开发人员在想要使用后者时使用前者是很常见的。也许使用setTimeout，因为这会导致代码异步运行，从而破坏了这种行为。难道是这样吗？
我还没有尝试使用 setTimeout 的最小值来达到所需的效果，但我现在就这样做。不过，我想弄清楚为什么会发生这种情况。
谢谢！
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.com/static/stack_overflow/redirect.html
- http://troy.onespot.com/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 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!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您假设在加载页面时设置 location.href 被视为替换是正确的。事实上有两种不同的行为。
第一个是，作为解析标签的结果运行的脚本中设置的 location.href 始终被解释为替换。 实现是为了镜像 Netscape 4 行为和 随后 调整。
第二个是，作为 onload 处理程序结果加载的任何新文档也始终被解释为替换。这是实现并且调整。
但我很好奇为什么您如此热衷于这样做，因为这意味着用户必须使用“后退”下拉菜单才能转到您页面之前的页面。 （如果继续将它们重定向到当前页面，则返回上一页是没有用的。）
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.)
我已经告诉你的猜测是正确的，但现在我看起来， HTML5 规范（链接到最相关的页面，因为很难链接到没有要求的页面）。
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).