window.location.hash 在 Chrome 中刷新?
我在网络上进行了一些窥探,发现 window.location.hash = "etc"
是一种广泛采用的方法,可以在不重新加载/刷新页面的情况下更新浏览器的位置。我已将其应用到我编写的这个示例中: http://dl .dropbox.com/u/1595444/locationExample/index.html
在 Safari 中运行良好,但是...
我注意到在 Chrome 10+ 中更改 hash
后:
以前有人遇到过这个问题吗?知道解决办法吗?
I was doing some snooping on the web and found window.location.hash = "etc"
to be a widely adopted method to update the browser's location without reloading / refreshing the page. I've applied that to this example I've cooked up: http://dl.dropbox.com/u/1595444/locationExample/index.html
Works well in Safari, but...
What I've noticed is that in Chrome 10+ upon changing hash
:
Has anyone run into this problem before? Know a fix?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
这里很可能发生两件事:
pushState
,但哈希更改是在相同的代码路径上)。
两者的解决方法是推迟哈希值的更新,直到用户完成滚动(您仍然可以立即更新当前项目下出现的白色条)。您可以通过以下方法来做到这一点:
因为看起来您正在使用 jQuery,所以有 debounce 插件 这可能会有所帮助。
There are most likely two things going on here:
pushState
, but hash changes areon the same code path).
A workaround for both would be to defer the updating of the hash until the user is done scrolling (you can still update the white bar that appears under the current item immediately). You can do this by having something like:
Since it looks like you're using jQuery, there are debouncing plugins that may be helpful.
我没有明确的答案,但首先我会尝试:
I don't have a definitive answer, but first I would try:
为我工作。事实上我花了很长时间才弄清楚这一点。 Firefox 现在还支持
history
对象,因此我们也许可以在几年内摆脱整个“哈希”事物。编辑:是的,重新加载是 Chrome 的一个错误。
Worked for me. And it actually took me a long time to figure this out. Firefox also supports the
history
object now, so we may be able to get rid of the whole "hash" thing in a few years.EDIT: Yes, the reloading thing is a Chrome bug.