Upgrade StorageZotero PDF 阅读和菜单操作卡顿（Zotero PDF reading and menu lag）
# Zotero PDF 阅读和菜单操作卡顿：一次与辅助功能接口有关的排查记录
## 中文分享稿
感谢 ChatGPT 在问题排查、性能记录分析和本文整理过程中提供的帮助。
我希望分享这次性能问题的排查过程和在本机有效的缓解方法，也想请开发者判断是否需要进一步的诊断信息，以定位底层原因。
### 问题表现与环境
我在 Windows 10 22H2（19045）上使用 Zotero 10.0.6（64 位），电脑配置为 i7-11700、32 GB 内存、RTX 3060 Ti，直接在本机操作。
最初只打开 4 篇文献就感觉卡顿。后来发现，问题不只是 PDF 滚动：停留在 PDF 阅读页面时，操作工具栏、菜单和设置也明显迟缓；切回文献库页面，响应会明显改善。
### 已尝试但没有明显解决的措施
- 禁用全部第三方插件并重启。
- 只保留一篇 PDF、更换其他 PDF。
- 重置 PDF 缩放、使用适合页面。
- 对比硬件加速开关的两种状态。
这些措施均未明显解决主要卡顿。电脑当时仍有充足可用内存。
### 性能记录提供的线索
在辅助排查中采集了两份约 30 秒的性能记录。第一份记录显示，主线程有大量 Windows UI Automation／辅助功能接口相关活动，包括 WM_GETOBJECT 消息和 UIAutomationCore.dll 调用。
随后将 `accessibility.force_disabled` 从 `0` 改为 `1`，完全退出并重启 Zotero，再次操作 PDF 和文献库并采样：
| 指标 | 修改前 | 修改后 |
| ---------------------------------------- | -------------:| ----------:|
| 主线程累计 CPU 时间 | 约 25 秒 | 约 10 秒 |
| 主线程事件延迟第 95 百分位 | 约 1,438 毫秒 | 约 26 毫秒 |
| WM_GETOBJECT 消息数 | 107,632 次 | 3,395 次 |
| 含 UIAutomationCore.dll 的主线程采样比例 | 约 80.1% | 约 6.2% |
修改后，我的实际体验也明显改善，PDF 阅读和工具栏操作已基本流畅。
两次手动操作不是严格一致的基准测试，表格不代表所有用户都能获得相同比例的性能提升。采样比例也不等于某个 DLL 自身的 CPU 耗时占比。
分析时，通过采样文件中的已加载模块地址范围，将原生调用栈地址映射到相应模块；这些调用栈尚未完成全面的符号解析。
### 具体操作与恢复方法
1. 在 Zotero 中打开“设置 → 高级 → 配置编辑器”。
2. 搜索 `accessibility.force_disabled`，记录当前值。
3. 将整数值从 `0` 改为 `1`。
4. 完全退出并重新启动 Zotero，测试相同 PDF 的滚动和菜单响应。
5. 如无改善或影响所需辅助工具，恢复原值并重启。
`0` 是默认自动模式，允许按需启用辅助功能接口；`1` 强制停用该接口。此项是诊断用隐藏设置，不是所有用户都应修改的常规优化选项。它会影响屏幕阅读器、依赖界面识别的语音控制及自动化工具。如果依赖这些功能，不宜直接关闭。
### 结论与尚未确定的部分
我的测试较强支持辅助功能／UI 自动化接口交互是本次主要卡顿的来源，但尚未确认最初触发请求的软件，也不能据此认定某个输入法、插件或显卡存在问题。本次排查使用过界面自动化工具，这也是需要向开发者披露的潜在干扰因素。
补充信息：Zotero 进程中加载了搜狗输入法组件，但仅凭加载记录，不能证明搜狗输入法导致了卡顿。
这是一例特定环境下的有效缓解方法，不是所有 Zotero 卡顿问题的通用修复。恢复插件后的情况应在后续补充。
请问两份对照性能记录或其他针对性测试是否有助于进一步定位原因？如有需要，我可以在检查记录内容后，通过合适的私密支持渠道提供性能文件。
### 参考资料
- [Microsoft：WM_GETOBJECT 消息用途](https://learn.microsoft.com/en-us/windows/win32/winauto/wm-getobject)
- [Mozilla 开发者：accessibility.force_disabled=1 属于诊断用途](https://bugzilla.mozilla.org/show_bug.cgi?id=1986303#c2)
---
## English version for the Zotero Forums
Acknowledgments: Thank you to ChatGPT for its help with troubleshooting, analyzing the performance profiles, and preparing this write-up.
### Suggested title
Zotero PDF reading and menu lag: a troubleshooting case involving accessibility interfaces
### Post
I would like to share how I investigated this performance issue and a workaround that helped on my system, and ask the developers whether further diagnostic information would help identify the underlying cause.
### Symptoms and environment
I use Zotero 10.0.6 (64-bit) on Windows 10 22H2 (build 19045), with an Intel Core i7-11700, 32 GB RAM, and an NVIDIA RTX 3060 Ti. I operate the computer locally, not through a remote desktop session.
Initially, Zotero felt noticeably laggy with only four papers open. I then noticed that the issue extended beyond PDF scrolling: while a PDF tab was active, interacting with the toolbar, menus, and settings was also sluggish. Switching to the library tab greatly improved responsiveness.
### Measures that did not substantially resolve the issue
- Disabling all third-party plugins and restarting Zotero.
- Keeping only one PDF open and trying different PDFs.
- Resetting the PDF zoom and using fit-to-page.
- Comparing hardware acceleration enabled and disabled.
None of these measures substantially resolved the main lag. The computer still had ample available memory at the time.
### Findings from the performance profiles
Two approximately 30-second performance profiles were collected during assisted troubleshooting. The first showed extensive Windows UI Automation / accessibility-interface activity on the main thread, including WM_GETOBJECT messages and UIAutomationCore.dll calls.
I then changed `accessibility.force_disabled` from `0` to `1`, fully quit and restarted Zotero, and collected another profile while interacting with the PDF view and library view:
| Metric | Before (0) | After (1) |
| ---------------------------------------------------------- | --------------:| -----------:|
| Main-thread CPU time | about 25 s | about 10 s |
| Main-thread event-delay p95 | about 1,438 ms | about 26 ms |
| WM_GETOBJECT marker count | 107,632 | 3,395 |
| Main-thread sampled stacks containing UIAutomationCore.dll | about 80.1% | about 6.2% |
After the change, my experience also improved substantially: PDF reading and toolbar interactions were basically smooth.
The two manually performed sequences were not a strictly identical benchmark, and the table does not imply that other users will see the same percentage improvement. Stack-presence percentages are not exclusive CPU-time attribution.
Native addresses were mapped to modules using the loaded-library address ranges in the profiles; the stacks have not been fully symbolicated.
### Steps and how to revert
1. In Zotero, open Settings → Advanced → Config Editor.
2. Search for `accessibility.force_disabled` and note its current value.
3. Change the integer value from `0` to `1`.
4. Fully quit and restart Zotero, then test scrolling and menu responsiveness with the same PDF.
5. If it does not help or interferes with required assistive tools, restore the original value and restart.
`0` is the default automatic mode, allowing accessibility interfaces to be enabled when needed; `1` forces them off. This is a hidden diagnostic setting, not a general optimization that all users should apply. It affects screen readers, voice-control tools that rely on interface recognition, and automation tools. Users who rely on these features should not simply disable the interfaces.
### Conclusions and remaining uncertainties
My tests provide strong support for accessibility / UI Automation interactions being the source of the main lag in this case. However, the software that initially triggered the requests has not been identified, and the results do not establish that a particular input method, plugin, or graphics card is at fault. UI automation tools were used during troubleshooting, which is a potential confounding factor that should be disclosed to the developers.
Additional context: Sogou input-method modules were loaded in the Zotero process, but their presence alone does not establish that Sogou caused the lag.
This is a workaround that helped in a particular environment, not a universal fix for Zotero performance problems. Results after re-enabling plugins should be added in a follow-up.
Would the paired performance profiles or another targeted test help identify the underlying cause? If needed, I can review the contents and provide the profiles through an appropriate private support channel.
### References
- [Microsoft: WM_GETOBJECT message](https://learn.microsoft.com/en-us/windows/win32/winauto/wm-getobject)
- [Mozilla developer: accessibility.force_disabled=1 is intended for diagnosis](https://bugzilla.mozilla.org/show_bug.cgi?id=1986303#c2)
---
## 中文分享稿
感谢 ChatGPT 在问题排查、性能记录分析和本文整理过程中提供的帮助。
我希望分享这次性能问题的排查过程和在本机有效的缓解方法，也想请开发者判断是否需要进一步的诊断信息，以定位底层原因。
### 问题表现与环境
我在 Windows 10 22H2（19045）上使用 Zotero 10.0.6（64 位），电脑配置为 i7-11700、32 GB 内存、RTX 3060 Ti，直接在本机操作。
最初只打开 4 篇文献就感觉卡顿。后来发现，问题不只是 PDF 滚动：停留在 PDF 阅读页面时，操作工具栏、菜单和设置也明显迟缓；切回文献库页面，响应会明显改善。
### 已尝试但没有明显解决的措施
- 禁用全部第三方插件并重启。
- 只保留一篇 PDF、更换其他 PDF。
- 重置 PDF 缩放、使用适合页面。
- 对比硬件加速开关的两种状态。
这些措施均未明显解决主要卡顿。电脑当时仍有充足可用内存。
### 性能记录提供的线索
在辅助排查中采集了两份约 30 秒的性能记录。第一份记录显示，主线程有大量 Windows UI Automation／辅助功能接口相关活动，包括 WM_GETOBJECT 消息和 UIAutomationCore.dll 调用。
随后将 `accessibility.force_disabled` 从 `0` 改为 `1`，完全退出并重启 Zotero，再次操作 PDF 和文献库并采样：
| 指标 | 修改前 | 修改后 |
| ---------------------------------------- | -------------:| ----------:|
| 主线程累计 CPU 时间 | 约 25 秒 | 约 10 秒 |
| 主线程事件延迟第 95 百分位 | 约 1,438 毫秒 | 约 26 毫秒 |
| WM_GETOBJECT 消息数 | 107,632 次 | 3,395 次 |
| 含 UIAutomationCore.dll 的主线程采样比例 | 约 80.1% | 约 6.2% |
修改后，我的实际体验也明显改善，PDF 阅读和工具栏操作已基本流畅。
两次手动操作不是严格一致的基准测试，表格不代表所有用户都能获得相同比例的性能提升。采样比例也不等于某个 DLL 自身的 CPU 耗时占比。
分析时，通过采样文件中的已加载模块地址范围，将原生调用栈地址映射到相应模块；这些调用栈尚未完成全面的符号解析。
### 具体操作与恢复方法
1. 在 Zotero 中打开“设置 → 高级 → 配置编辑器”。
2. 搜索 `accessibility.force_disabled`，记录当前值。
3. 将整数值从 `0` 改为 `1`。
4. 完全退出并重新启动 Zotero，测试相同 PDF 的滚动和菜单响应。
5. 如无改善或影响所需辅助工具，恢复原值并重启。
`0` 是默认自动模式，允许按需启用辅助功能接口；`1` 强制停用该接口。此项是诊断用隐藏设置，不是所有用户都应修改的常规优化选项。它会影响屏幕阅读器、依赖界面识别的语音控制及自动化工具。如果依赖这些功能，不宜直接关闭。
### 结论与尚未确定的部分
我的测试较强支持辅助功能／UI 自动化接口交互是本次主要卡顿的来源，但尚未确认最初触发请求的软件，也不能据此认定某个输入法、插件或显卡存在问题。本次排查使用过界面自动化工具，这也是需要向开发者披露的潜在干扰因素。
补充信息：Zotero 进程中加载了搜狗输入法组件，但仅凭加载记录，不能证明搜狗输入法导致了卡顿。
这是一例特定环境下的有效缓解方法，不是所有 Zotero 卡顿问题的通用修复。恢复插件后的情况应在后续补充。
请问两份对照性能记录或其他针对性测试是否有助于进一步定位原因？如有需要，我可以在检查记录内容后，通过合适的私密支持渠道提供性能文件。
### 参考资料
- [Microsoft：WM_GETOBJECT 消息用途](https://learn.microsoft.com/en-us/windows/win32/winauto/wm-getobject)
- [Mozilla 开发者：accessibility.force_disabled=1 属于诊断用途](https://bugzilla.mozilla.org/show_bug.cgi?id=1986303#c2)
---
## English version for the Zotero Forums
Acknowledgments: Thank you to ChatGPT for its help with troubleshooting, analyzing the performance profiles, and preparing this write-up.
### Suggested title
Zotero PDF reading and menu lag: a troubleshooting case involving accessibility interfaces
### Post
I would like to share how I investigated this performance issue and a workaround that helped on my system, and ask the developers whether further diagnostic information would help identify the underlying cause.
### Symptoms and environment
I use Zotero 10.0.6 (64-bit) on Windows 10 22H2 (build 19045), with an Intel Core i7-11700, 32 GB RAM, and an NVIDIA RTX 3060 Ti. I operate the computer locally, not through a remote desktop session.
Initially, Zotero felt noticeably laggy with only four papers open. I then noticed that the issue extended beyond PDF scrolling: while a PDF tab was active, interacting with the toolbar, menus, and settings was also sluggish. Switching to the library tab greatly improved responsiveness.
### Measures that did not substantially resolve the issue
- Disabling all third-party plugins and restarting Zotero.
- Keeping only one PDF open and trying different PDFs.
- Resetting the PDF zoom and using fit-to-page.
- Comparing hardware acceleration enabled and disabled.
None of these measures substantially resolved the main lag. The computer still had ample available memory at the time.
### Findings from the performance profiles
Two approximately 30-second performance profiles were collected during assisted troubleshooting. The first showed extensive Windows UI Automation / accessibility-interface activity on the main thread, including WM_GETOBJECT messages and UIAutomationCore.dll calls.
I then changed `accessibility.force_disabled` from `0` to `1`, fully quit and restarted Zotero, and collected another profile while interacting with the PDF view and library view:
| Metric | Before (0) | After (1) |
| ---------------------------------------------------------- | --------------:| -----------:|
| Main-thread CPU time | about 25 s | about 10 s |
| Main-thread event-delay p95 | about 1,438 ms | about 26 ms |
| WM_GETOBJECT marker count | 107,632 | 3,395 |
| Main-thread sampled stacks containing UIAutomationCore.dll | about 80.1% | about 6.2% |
After the change, my experience also improved substantially: PDF reading and toolbar interactions were basically smooth.
The two manually performed sequences were not a strictly identical benchmark, and the table does not imply that other users will see the same percentage improvement. Stack-presence percentages are not exclusive CPU-time attribution.
Native addresses were mapped to modules using the loaded-library address ranges in the profiles; the stacks have not been fully symbolicated.
### Steps and how to revert
1. In Zotero, open Settings → Advanced → Config Editor.
2. Search for `accessibility.force_disabled` and note its current value.
3. Change the integer value from `0` to `1`.
4. Fully quit and restart Zotero, then test scrolling and menu responsiveness with the same PDF.
5. If it does not help or interferes with required assistive tools, restore the original value and restart.
`0` is the default automatic mode, allowing accessibility interfaces to be enabled when needed; `1` forces them off. This is a hidden diagnostic setting, not a general optimization that all users should apply. It affects screen readers, voice-control tools that rely on interface recognition, and automation tools. Users who rely on these features should not simply disable the interfaces.
### Conclusions and remaining uncertainties
My tests provide strong support for accessibility / UI Automation interactions being the source of the main lag in this case. However, the software that initially triggered the requests has not been identified, and the results do not establish that a particular input method, plugin, or graphics card is at fault. UI automation tools were used during troubleshooting, which is a potential confounding factor that should be disclosed to the developers.
Additional context: Sogou input-method modules were loaded in the Zotero process, but their presence alone does not establish that Sogou caused the lag.
This is a workaround that helped in a particular environment, not a universal fix for Zotero performance problems. Results after re-enabling plugins should be added in a follow-up.
Would the paired performance profiles or another targeted test help identify the underlying cause? If needed, I can review the contents and provide the profiles through an appropriate private support channel.
### References
- [Microsoft: WM_GETOBJECT message](https://learn.microsoft.com/en-us/windows/win32/winauto/wm-getobject)
- [Mozilla developer: accessibility.force_disabled=1 is intended for diagnosis](https://bugzilla.mozilla.org/show_bug.cgi?id=1986303#c2)
---
What we'd want to know is which program is turning on accessibility support. To check:
1. Set accessibility.force_disabled back to 0 and restart Zotero.
2. Open a PDF and wait until the lag starts.
3. Go to Tools → Developer → Run JavaScript and run this:
[Services.appinfo.accessibilityEnabled, Services.appinfo.accessibilityInstantiator]
4. Post the result here.
The second value should name the program or DLL that turned it on.
Since the Sogou input method is loaded into the Zotero process, it would also help to temporarily switch to the Microsoft Pinyin IME (or exit Sogou entirely) with the default setting and see whether the lag goes away. Make sure no automation tools are running while you test, since those can trigger the same thing.