CDHJS

怀疑是无法输入空格造成的，尝试在用户目录的 weasel.custom.yaml 这个文件里面，设置 ``` patch: style/inline_preedit: true ``` 相关：#1411 #1462

> 如果要合并，这个_inlinePreeditEnabled就是没有用的状态了，还有下面的一个位置也是要调整。 其他，我觉得再观察一段时间再看？ 另外我试过一下firefox的设置窗口里面，这样一样没有解决问题的，Windows 10 64bit 在我的系统上（Windows 10 22H2）Floorp 11.20.0 (64 位) | Firefox: 128.5.0和Firefox 132.0.2设置界面都正常打字且定位正常，使用GitHub Actions的编译。 至于其它需要调整的内容，我并不会C++，我只是找到出错的地方并注释掉了

问题可能出在 https://github.com/rime/weasel/blob/37c8fa161a221a263bb439a1158ba401c0cf90a3/WeaselTSF/Composition.cpp#L241-L242 注释掉任意一行都可以正常打字

> @CDHJS 老哥我看你描述是用GPT做的DEBUG，具体是咋实现的呢？用的什么工具呢？ 我最早的思路其实是去找“winapi获取活动窗口句柄”误打误撞找到了 https://github.com/rime/weasel/blob/37c8fa161a221a263bb439a1158ba401c0cf90a3/WeaselTSF/Composition.cpp#L188 然后fork并删掉了整个代码块，我没装C++的编译环境所以用Actions编译，也是误打误撞删掉了 https://github.com/rime/weasel/blob/37c8fa161a221a263bb439a1158ba401c0cf90a3/WeaselTSF/Composition.cpp#L205 发现bug不存在了，**上面的commit只是错误的以为bug来源是GetForegroundWindow把整块代码扔给GPT去重写了而已** 以及我到现在没找到m_client是什么（VSCode只能找字符串），但我注释掉之后bug消失了，我fork的actions里最新的结果你可以试试

我测试了Chromium，Floorp，Edge，VSCode，Steam，wails，单独tao，winit+wry，webview2-rs（wry的上游）都正常，只有tao+wry和tauri会卡死，不过删除m_client.UpdateInputPosition(rc);的版本能正常运行，以及删除https://github.com/rime/weasel/blob/37c8fa161a221a263bb439a1158ba401c0cf90a3/WeaselUI/WeaselPanel.cpp#L1213-L1214 也能正常运行，但定位会在桌面左上角不动 卡死时【Webview tauri主进程 算法服务】加起来的CPU会有一个接近单核满载的占用，并且其中一个Webview进程内存缓慢增加（内存泄露？） 如果有托盘图标菜单的话右键托盘图标会解除卡死并关闭菜单，操作了几步就需要右键几下 如果点击了别的窗口卡死的UI会跟着新的窗口移动，如果此时输入会出现两个UI，新出现的UI正常

在tao+wry如果给 https://github.com/tauri-apps/tao/blob/fa9aaa6066dcc0316d57038fc1b1e3353dc5c3e7/src/platform_impl/windows/event_loop.rs#L248 后面加上println!("{:?}", msg); 会一直输出： MSG { hwnd: HWND(0x608b0), message: 15, wParam: WPARAM(0), lParam: LPARAM(0), time: 21220500, pt: POINT { x: 1457, y: 644 } } 而非正常阻塞，此时移动鼠标POINT的值会实时变化（排除过多相同消息导致阻塞） 并且webview不会未响应（如果阻塞会导致未响应，比如sleep）

使用api-monitor可以观察到 GetMessageW的DefSubclassProc出现了死循环，在wry中可以找到：https://github.com/tauri-apps/wry/blob/cbbcccc38af7d900a0f8f7fa5ea5e6667765ed81/src/webview2/mod.rs#L1158-L1161 删除后卡死消失 在此仓库可以找到： https://github.com/rime/weasel/blob/588a31f8eedf6066e5b6a1cc7f010ed528154445/include/wtl/atlframe.h#L1506 可能是诱发此bug的原因 附上chatGPT的解释：  @fxliang 希望对修复这个问题有所帮助

另外想请教一下m_client.UpdateInputPosition在什么情况下会使用到，在我的使用中是否有这行的版本表现并无不同 Floorp、Chromium在输入后移动窗口UI会跟着移动，其它多数应用会停留在原本的位置在按下键盘后跳到正确的位置，tao+wry/tauri移动窗口则会销毁UI或始终保持在原位，哪一种情况是正确的feature？

> > 使用api-monitor可以观察到 GetMessageW的DefSubclassProc出现了死循环，在wry中可以找到：https://github.com/tauri-apps/wry/blob/cbbcccc38af7d900a0f8f7fa5ea5e6667765ed81/src/webview2/mod.rs#L1158-L1161 删除后卡死消失 在此仓库可以找到： > > https://github.com/rime/weasel/blob/588a31f8eedf6066e5b6a1cc7f010ed528154445/include/wtl/atlframe.h#L1506 > > > > 可能是诱发此bug的原因 > > 附上chatGPT的解释： > >  > > @fxliang 希望对修复这个问题有所帮助 > > 一些猜想：WeaselUI中未注册WM_WINDOWPOSCHANGED 的响应回调，那这个消息会向上传递到上一层应用的窗口对象；然后如你指出的状态似乎这个应用框架会手动触发一次WM_WINDOWPOSCHANGED消息，tsf中有注册如果光标位置变化的话，会响应调整输入框位置，这个又会调用一次SetWindowPos，于是死循环了？ > >...

在任何程序都会有类似的情况，我是使用的雾凇拼音，只要打字就会造成主进程卡顿，这是tsf的原理引起的 下图为Minecraft 1.20.5的F3+2，可以很清楚的看到在打字时会阻塞主进程并降低帧数，按住时直接卡死，点按阻塞时长逐步上升 一个可能的修复方法是用多线程/进程把耗时任务放到其它进程避免阻塞主进程/使用简单快速的输入方案/关闭输入法 看#1159 的情况可能是Windows的锅，在不该启动输入法的情况下启动了输入法 微软拼音也有类似的问题，但因为速度快所以帧数影响较小，并且有上限