fix(windows): 补齐 QA helper-window 的原生交互语义#184
Conversation
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Sorry @Cooper-X-Oak, you have reached your weekly rate limit of 500000 diff characters.
Please try again later or upgrade to continue using Sourcery
There was a problem hiding this comment.
Sorry @Cooper-X-Oak, you have reached your weekly rate limit of 500000 diff characters.
Please try again later or upgrade to continue using Sourcery
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ac51f719ef
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| let toolbar_height = 32; | ||
| let right_controls_width = 76; | ||
| let draggable_right = (rect.right - right_controls_width).max(0); |
There was a problem hiding this comment.
WM_NCHITTEST coordinates and GetClientRect are in physical pixels, but the drag thresholds here (toolbar_height = 32, right_controls_width = 76) are hard-coded as if they were CSS/logical pixels. On Windows displays using 125%/150% scaling, the non-draggable controls area becomes too small and the draggable caption zone intrudes into the pin/close buttons, so clicks on controls can be interpreted as drag starts. Please derive these bounds from the current DPI (or from runtime window scale factor) before comparing against hit-test coordinates.
Useful? React with 👍 / 👎.
|
Codex:P1 |
2 participants
摘要
Closes #153
这张 PR 是从 upstream 干净基线 重新切出来的代码修复分支，目标只做一件事：
补齐 Windows 上 QA helper-window 的原生交互语义。
这里说的交互语义，主要是：
这张 PR 不再继续尝试共享拖动承载，而是改成 Windows 原生消息层 的拖动实现。
这张 PR 解决什么
当前我们已经把问题范围收得很小了：
Ctrl+Shift+;正常所以这张 PR 不再是“大而全 QA 修复”，而是聚焦在：
修复内容
这次实际改动主要有三类：
WM_NCHITTEST -> HTCAPTION为什么要这样做
这次已经验证出来：
所以这张 PR 的核心不是“改一段前端拖动代码”，而是：
按 Windows 的原生交互规范，补齐同一个产品目标。
范围边界
这张 PR 不包含：
也就是说，这张 PR 只属于：
验证情况
已完成：
npm run buildcargo buildQaPanel.tsx没有拖动承载实现Ctrl热键正常仍建议 reviewer 再做一次 Windows 实机确认：
关联关系