Greasy Fork

对于 vd_source 的一个思路：拦截 navigation 事件。 因为这个事情我发了个文章：https://www.zhihu.com/question/540759717/answer/2553044518 根据下面评论的提示可以用 window.navigation.addEventListener('navigate', e => e.preventDefault()) 来拦截事件。 也就是这个事件也是可以监听的了。 我昨天还在想重写的事情，那么直接监听这个事件然后判断是否需要清理就应该是更好的选择了。 我简单写了一个在最下面，不过逻辑有点尴尬，因为我觉得 replaceState 可能也会被其他单页应用的场景应用（可能 b 站没有？如果没有那就直接干掉就行了），所以不能直接拦截。

因此我就加了个判断看他这个链接清理之后是不是还有用，然后再调用一次 replaceState，但是由此就会再次被时间监听捕获到，虽然也会被我们判断掉，但是还是会多进行一次 clean。

所以这个应该不是最优雅的方式。 不过目前这样就不会出现 vd_source 闪一下的情况了。 总之监听拦截事件的方向应该是对的。

优化思路上，我有两个想法，首先还是重写 replaceState ，这样就不用考虑循环调用了。 但是昨天尝试后发现会一直刷新。 其次就是我们给他挂一个 Proxy。

    window.navigation.addEventListener('navigate', e => {
     const newURL = clean(e.destination.url)
     if(e.destination.url!=newURL) {
         if(newURL == window.location.href) return // 如果清理后和原来一样就直接返回
         // 否则就处理清理后的链接
         window.history.replaceState(window.history.state, "", newURL)
         e.preventDefault()
         return
     }
     console.warn("不拦截", e)
    });

事件回调的确是更优雅的方式，不过navigate倒是第一次听说🤣

循环一次感觉不是什么问题，本来就在异步里。上述代码我把e.preventDefault()提前了，因为stardust-video.js会多次调用history.replaceState，与window.location.href比较的话后几次直接就相等 return 了，达不到清理效果。

不过这navigation要求浏览器版本太高了，对大部分用户基本没用

好的好的！orz 确实我忘了兼容性这点了，在这个之前我都没注意到过还能监听这个事件。