5

我刚刚在 Firefox 3.6/Mac 中遇到了一些奇怪的行为。不过，我怀疑这是一般的 Firefox 行为。

我创建了两个非常简单的测试页面，它们更改window.location.href属性以导航到新 URL：

如果您对任一文件尝试以下操作：

  • 打开一个新的/空白浏览器选项卡。
  • 粘贴 URL 并点击“Enter”。

您会注意到两者之间的一个区别：使用第一个链接时，浏览器的“返回”按钮被禁用；使用第二个，它已启用并按我的预期工作。

两个脚本之间的唯一区别是后者在更改之前设置了一秒超时window.location.href。

我不知道为什么会发生这种情况，我正在尝试实现第二个脚本的行为（“返回”按钮继续按预期工作），而不会给用户造成任何延迟。

window.location.href我最好的猜测是，也许 Firefox 通过设置与使用该方法相同的方式来处理立即“重定向” window.location.replace()，因为我认为开发人员在打算使用后者时使用前者是很常见的。也许使用setTimeout，因为这会导致代码异步运行，会破坏这种行为。会是这样吗？

我还没有尝试过最小的值setTimeout来达到预期的效果，但我现在会这样做。不过，我想弄清楚为什么会发生这种情况。

谢谢！

4

2 回答 2

2

您假设在加载页面时设置 location.href 被视为替换是正确的。实际上有两种不同的行为。

第一个是从作为解析标记结果运行的脚本中设置 location.href 始终被解释为替换。这是为了反映 Netscape 4 的行为而实现的，随后进行了 调整。

第二个是由于 onload 处理程序加载的任何新文档也总是被解释为替换。这是实施和调整。

但我很好奇您为什么如此热衷于这样做，因为这意味着用户必须使用“后退”下拉菜单才能转到您的页面之前的页面。（如果继续将它们重定向到当前页面，则返回一页将毫无用处。）

于 2011-01-18T00:53:29.103 回答
1

我最好的猜测是，也许 Firefox 通过将 window.location.href 设置为与使用 window.location.replace() 方法相同来处理立即“重定向”，因为我认为开发人员在打算使用前者时使用前者是很常见的后者。也许使用 setTimeout，因为这会导致代码异步运行，会破坏这种行为。会是这样吗？

有人告诉我你的猜测是正确的，但现在我看， HTML5 规范中似乎没有提到这个要求（链接到最相关的页面，因为很难链接到没有要求）。

于 2010-10-27T04:27:28.000 回答