导致浏览器下载任务卡顿缓冲的问题并未解决

[BenmiaoZ]

描述错误

271 相关问题在版本更新后并未解决

经测试，问题复现过程如下：

• 浏览器下载卡顿，禁用拓展程序后下载恢复正常
• 卸载工具箱，重新安装，安装后浏览器下载正常
• 修改部分设置，浏览器下载正常
• 使用工具箱下载一张绘画图片，当前浏览器下载正常
• 关闭浏览器并重新打开，浏览器下载卡顿、需加载数秒

浏览器以及版本（请填写以下信息）：

Chrome 版本 128.0.6613.120（正式版本） （64 位）

[leoding86]

这个问题一致没有找到具体的症结所在，最新的处理方式是移除对事件onDeterminingFilename的监听。似乎关闭浏览器再打开并没有重新初始化插件导致事件监听出现异常🤔

[BenmiaoZ]

这个问题一致没有找到具体的症结所在，最新的处理方式是移除对事件onDeterminingFilename的监听。似乎关闭浏览器再打开并没有重新初始化插件导致事件监听出现异常🤔

没有具体看代码，所以操作上我可以做什么来避免这个问题的出现吗？

[leoding86]

暂时没有办法避免，等会儿会提交一个版本，移除了对onDeterminingFilename的监听，这样就不会有延迟的问题。

不过之前监听这个事件是为了解决可能因其他带有保存功能的插件导致的命名异常问题，不排除之前的问题会重新出现😕

[BenmiaoZ]

之前的命名异常是因为异步保存，过程中文件名可能被修改，所以监听事件吗？ 重启浏览器、重载插件都没用，只能卸载插件重装才能恢复正常，是因为该监听事件从插件安装后第一次下载就开始且一直保持了吗？ 那是否可以考虑只在每次下载开始后监听，保证该次下载命名不出问题，下载完成后关闭监听或是将监听状态初始化至插件刚安装时的状态。 没有读代码，纯瞎掰扯，希望也许能提供有帮助的思路。

[leoding86]

通过文档没有找到可以移除这个事件的方法，也尝试过找profile完全关闭的检测方法用于手动重启插件，但是也没有找到。之前的做法是保证这个事件只会被监听一次，同时保证在监听函数中只调用一次suggest，就我的理解应该不会出现问题。

但是在调试的过程中发现，完全关闭一个profile浏览器并不会关闭插件的workservice，也就是事件监听并未移除，并且在重新打开profile后保存文件并不会进入事件监听函数。反正就非常奇怪🤔，并不确定是否是浏览器BUG。准备有时间的时候找下别的插件看下是怎么处理的。

[leoding86]

好像找到是什么原因了。onDeterminingFilename事件需要在插件启动的时候马上监听，而不是在保存文件的时候再开始监听。

[BenmiaoZ]

验证没问题，辛苦了