Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

新建前台标签页打开书签卡顿或无反应 #50

Closed
notgp2engine opened this issue Mar 29, 2024 · 16 comments
Closed

新建前台标签页打开书签卡顿或无反应 #50

notgp2engine opened this issue Mar 29, 2024 · 16 comments
Labels
duplicate This issue or pull request already exists question Further information is requested

Comments

@notgp2engine
Copy link

系统版本: Win11专业版 22631.3296
Chrome版本: 123.0.6312.86
具体表现为,点击书签栏的标签时可以正常打开,点击隐藏的书签时有卡顿,大概2~3秒左右才会打开,如果点击书签后移动鼠标会无法打开书签
Chrome++配置如图
11

@Bush2021
Copy link
Owner

Bush2021 commented Mar 29, 2024 via email

@Bush2021 Bush2021 added duplicate This issue or pull request already exists question Further information is requested labels Mar 29, 2024
@notgp2engine
Copy link
Author

#45 (comment)

我这边没有使用鼠标手势和快捷键之类的软件,只使用Chrome++

@Bush2021
Copy link
Owner

点击隐藏的书签时有卡顿

“隐藏的书签”指的是什么?

我这边没有使用鼠标手势和快捷键之类的软件,只使用Chrome++

请提供最小可复现配置。

@notgp2engine
Copy link
Author

点击隐藏的书签时有卡顿

“隐藏的书签”指的是什么?

我这边没有使用鼠标手势和快捷键之类的软件,只使用Chrome++

请提供最小可复现配置。

233

@notgp2engine
Copy link
Author

++

@Bush2021
Copy link
Owner

你录屏中的效果确实不正常,可惜我本地没能复现这个问题,隐藏书签在我这里表现也正常;

方便的话,可以把你的配置脱敏后发给我,我本地试试看。

@notgp2engine
Copy link
Author

notgp2engine commented Mar 29, 2024

你录屏中的效果确实不正常,可惜我本地没能复现这个问题,隐藏书签在我这里表现也正常;

方便的话,可以把你的配置脱敏后发给我,我本地试试看。

我这边试了一下,估计跟书签数量有关,书签数量少时打开是正常的
屏幕截图 2024-03-29 231916
当书签数量多到出现下拉箭头时打开标签开始感觉到延迟
屏幕截图 2024-03-29 232037
书签数量越多,卡顿感越明显

@Bush2021
Copy link
Owner

我这边试了一下,估计跟书签数量有关,书签数量少时打开是正常的
当书签数量多到出现下拉箭头时打开标签开始感觉到延迟
书签数量越多,卡顿感越明显

OK 我复现这个问题了,而且貌似是从 123 版本开始的。我有空看看能不能解决吧。

@Bush2021
Copy link
Owner

经测试,M123 引入了这个问题,M125 有所改善,初步认为是内核的问题。

@Ritchie1108
Copy link
Contributor

经测试,M123 引入了这个问题,M125 有所改善,初步认为是内核的问题。

遍历子节点那边改为步进搜索, 会改善一点

@Bush2021
Copy link
Owner

Bush2021 commented Apr 2, 2024

遍历子节点那边改为步进搜索, 会改善一点

我这边初步测试步进反而会更慢,但貌似不会卡死了。 db60ee6

你的情况一样吗?

@Ritchie1108
Copy link
Contributor

遍历子节点那边改为步进搜索, 会改善一点

我这边初步测试步进反而会更慢,但貌似不会卡死了。 db60ee6

你的情况一样吗?

实现不一样, 步进主要是针对 AccessibleChildren 这个接口, 第二个参数可以处理步进, 我递归遍历的时候和没处理过前的版本相比, 本地测试大概性能提升了有3, 4倍这样, 在隐藏书签塞了96个左右的情况下. 问了下群里的人他们认为是不卡或者可以接受的程度

还有就是在 M123 下我测试的时候 get_accChildCount 这个接口在上面96个隐藏书签那边, 调用都能耗时30ms~800多ms, 很奇怪, 我不确定是不是 M123 开始才出现的情况, 所以我在递归遍历的时候也减少了这个接口的调用次数

@Bush2021
Copy link
Owner

Bush2021 commented Apr 3, 2024

实现不一样, 步进主要是针对 AccessibleChildren 这个接口, 第二个参数可以处理步进, 我递归遍历的时候和没处理过前的版本相比, 本地测试大概性能提升了有3, 4倍这样, 在隐藏书签塞了96个左右的情况下. 问了下群里的人他们认为是不卡或者可以接受的程度

还有就是在 M123 下我测试的时候 get_accChildCount 这个接口在上面96个隐藏书签那边, 调用都能耗时30ms~800多ms, 很奇怪, 我不确定是不是 M123 开始才出现的情况, 所以我在递归遍历的时候也减少了这个接口的调用次数

感谢,我抽空重新测试一下。方便邮件告诉我群号吗?Bush#outlook.my

我测试下来应该就是 M123 引入的问题,而且我只发现 get_accChildCount 在找隐藏的书签或书签文件夹的时候调用耗时过长,我本地大概是 500ms,M125 变成 50ms 左右,所以我才怀疑是内核的修改导致的。

@Ritchie1108
Copy link
Contributor

实现不一样, 步进主要是针对 AccessibleChildren 这个接口, 第二个参数可以处理步进, 我递归遍历的时候和没处理过前的版本相比, 本地测试大概性能提升了有3, 4倍这样, 在隐藏书签塞了96个左右的情况下. 问了下群里的人他们认为是不卡或者可以接受的程度
还有就是在 M123 下我测试的时候 get_accChildCount 这个接口在上面96个隐藏书签那边, 调用都能耗时30ms~800多ms, 很奇怪, 我不确定是不是 M123 开始才出现的情况, 所以我在递归遍历的时候也减少了这个接口的调用次数

感谢,我抽空重新测试一下。方便邮件告诉我群号吗?Bush#outlook.my

我测试下来应该就是 M123 引入的问题,而且我只发现 get_accChildCount 在找隐藏的书签或书签文件夹的时候调用耗时过长,我本地大概是 500ms,M125 变成 50ms 左右,所以我才怀疑是内核的修改导致的。

我测试的时候 AccessibleChildren 影响也挺大, 所以才对这个接口改成步进的方式, 而不是一次性取出所有子节点
🤣就一吹水群

@Bush2021
Copy link
Owner

Bush2021 commented Apr 3, 2024

我测试的时候 AccessibleChildren 影响也挺大, 所以才对这个接口改成步进的方式, 而不是一次性取出所有子节点 🤣就一吹水群

所以就是只有书签这边的遍历有问题对吧?步进可以暂时缓解下,可能得研究下书签组件才行,或者等官方修复吧?

我们邮件交换下方便的联系方式?私下交流可能方便些。

@Bush2021
Copy link
Owner

Bush2021 commented Apr 6, 2024

@notgp2engine 经测试该问题已经在 Chrome 123.0.6312.106 中解决。

@Bush2021 Bush2021 closed this as completed Apr 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
duplicate This issue or pull request already exists question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants