[小Tip]Webkit下设置hash的一个坑

今天要说的hash，就是浏览器地址栏URL里#之后的那堆东东，一般用来定位到页面中的命名锚点，或者用来维护纯客户端的页面跳转历史状态。这是几年前的话题了，大 家肯定都知道，我的博客也写过相关文章。

hash的最大好处是改变它不会导致页面刷新，在history.pushState/replaceState问世之前，它无疑是JS端维持页面状态最好的方案。但 我今天踩到一个坑：Webkit下，在frameset引入的页面中改变最外层的location.hash，居然会导致页面刷新，测试了最新版的Safari和Ch rome，都是如此；其他内核的浏览器都无此问题。

最后，我采用的解决方案也比较简单：既然问题是出在高级的webkit下，直接调用history.replaceState代替给history.hash赋值就好 了。只是我之前还从未想过，replaceState这么"高级"的接口还可以用来修这么弱智的Bug。。。

if(QW.Browser.webkit) {

        top.history.replaceState(null, top.document.title, '#'+hash);
    } else {
        top.location.hash = hash;
    }

这里还有一个简单的demo。这个坑之所以很少被人踩到，是因为踩坑条件比较特殊：改变hash的页面必须是frameset方式引入，iframe引入的页面没有问 题。如今用frameset的人越来越少了，踩坑机会也越来越小了，所以即使有人早就报了bug，webkit一直也不修。

顺便说下，这个坑是我今天改QWrap文档踩到的。现在QWrap文档终于可以把某个接口详情页URL复制下来发给别人了，也终于加上了评论功能，用的是disqus 。

专题「浏览器」的其他文章 »

• iOS 10 Safari 视频播放新政策 (Oct 07, 2016)
• Chrome 中 scrollingElement 的变化 (Apr 16, 2016)
• 域名小知识：Public Suffix List (Nov 28, 2015)
• window.opener.location 安全风险讨论 (Oct 09, 2015)
• 使用 SRI 增强 localStorage 代码安全 (Sep 26, 2015)
• Subresource Integrity 介绍 (Sep 23, 2015)
• 移动 Web 与 JavaScript 定时器 (Mar 27, 2014)
• Chrome 和 Web Fonts 二三事 (Mar 24, 2014)
• Webkit 异步加载 CSS 的奇怪现象 (Dec 25, 2013)
• 小成本实现部分选中的复选框 (Dec 22, 2013)