andywang425
andywang425
看起来隐私獾作者已经意识到这个问题了 https://github.com/EFForg/privacybadger/issues/2968
> This should be fixed in Chrome as of Chrome version 128. @Mishasama Could you take a look, and perhaps update your Chrome Web Store review? Thank you! I just...
可以先尝试把无关的用户脚本和浏览器拓展都关掉，看看脚本能运行不
@catscarlet 你的复现方法没什么问题，删cookie这步是必要的。LIVE_BUVID这个cookie是在用户第一次打开任意直播间网页后的几秒中内被设置的，一年后才会过期。但有些情况下可能是网络卡或者B站网页的代码比较卡，10秒的超时时间内还没设置好这个cookie，脚本就会报错。绝大多数用户不会遇到这个Bug，因为装这个脚本前都已经登录B站且看过直播。对于脚本来说没有什么很好的解决办法，要么就增加一点超时时间。 楼主这个可能还是和其它脚本有冲突，否则不会刷新过页面还没恢复正常。
我估计是因为BLTH hook了xmlHttpRequest和fetch。而且运行时期太晚hook就没用了，所以脚本不得不在document-start阶段运行。之后会想想办法。
> 也许可以考虑把一些不必要start的功能分开？避免整个脚本都失效。 再做一个脚本？这还是算了吧，真没那么多精力。 > 现在还有个问题，在未开播直播间也不显示面板按钮，但是控制台有运行日志的 > 在龟速网络下会接近100%复现。建议为此功能增加轮询重试。 其实已经有轮询重试了，还报错大概是因为是超时时间太短了（3秒），之后我可以调整一下参数，或者用MutationObserver监听的方式来取代轮询。
> 当然不是……只是将一些无须start的功能加个等待，以达到部分document-idle的效果。这样也许还能提高性能表现。 懂了。脚本现在内部有一套模块的运行时机管理机制，每个模块有自己的运行时机，模块会等到自己的运行时机再运行。要提高和别的脚本的兼容性的话我觉得还是得在hook方面下手，尽量减少副作用。 > 那不可能啊……只要页面完全加载完毕了，你再次轮询的话就不应该会有问题。但事实上页面加载完了它也没有继续尝试了，在控制台也只看到一条超时报错，并没有轮询的迹象。 看控制台确实是看不出来的，我估计还是超时时间太短。下个版本中我用监听取代了轮询，超时时间延长到了10秒，到时候你再试试。
刚刚更新了7.1.5
等会我测试一下看看
确实是失效的。目前不太清楚触发入场提示的究竟是什么，等找到原因后会修复。