SetWindowPos跨屏移动窗口时Chrome全屏窗口无法正常迁移的问题

核心问题根源 #

现有实现未覆盖现代浏览器的特殊窗口机制，尤其是Chromium内核浏览器的全屏窗口并不适配传统Win32通用操作逻辑，这是导致移动失效、退出全屏后窗口跳回原屏的核心原因。

关键遗漏的处理步骤 #

• 全屏窗口的判断逻辑完全错误
  目前通过style & WS_OVERLAPPEDWINDOW位运算判断全屏的方式没有实际依据：真正的全屏窗口（包括Chrome F11触发的系统全屏、YouTube网页级沉浸式全屏）依然会保留标准窗口样式，只是窗口边界与屏幕完整边界完全重合，同时隐藏边框和任务栏。正确判断方式是通过GetWindowRect获取窗口实际矩形，对比所属屏幕的全边界尺寸，尺寸完全匹配即判定为全屏状态，无需靠位运算判断窗口样式。
  另外，Chrome进入全屏时会临时创建独立的全屏顶层窗口，原主窗口会被隐藏。当前代码枚举hwnd拿到的是已经被隐藏的旧主窗口，对它执行的位置修改根本不会作用到实际显示的全屏窗口上。
• 窗口状态缓存方式失效
  目前手动计算窗口相对屏幕位置的逻辑，对最大化、全屏窗口完全不适用：这类窗口的矩形是满屏坐标，计算出来的相对位置并非窗口正常状态下的真实位置。
  应该直接使用GetWindowPlacement API获取窗口的完整状态，这个接口会自动缓存窗口在正常非最大化、非全屏状态下的坐标和尺寸，完全不需要手动计算相对位置，对各类浏览器的特殊窗口状态兼容性远高于手动读取矩形。
• 操作顺序完全错误
  目前的操作链路（还原最小化状态→改样式移除全屏效果→还原最大化状态→设置窗口位置→恢复最大化→恢复全屏）对普通窗口有效，但对全屏浏览器会出现操作被覆盖的问题：在浏览器还保留全屏状态的前提下直接修改窗口位置，浏览器自身的渲染逻辑会立刻把窗口拉回原屏幕位置。
  正确的操作顺序为：
  1. 枚举目标hwnd同进程的所有顶层窗口，定位到实际显示的全屏窗口句柄，不要只依赖初始枚举的主窗口句柄
  2. 先还原处于最小化状态的窗口
  3. 如果检测到全屏状态，先通过WM_SYSCOMMAND消息通知浏览器退出全屏，等待窗口边界完全更新为正常状态的矩形后，再执行位置设置
  4. 位置设置完成后，再根据提前缓存的状态逐次恢复窗口
• 状态恢复逻辑不兼容浏览器的内部机制
  目前靠修改窗口样式恢复全屏的方式，对浏览器完全无效：浏览器的全屏状态是应用内部维护的，根本不依赖Win32窗口样式判断。这种硬改样式的操作，会导致浏览器内部的全屏位置缓存始终保留原屏幕的坐标，一旦退出全屏就会跳回原位置。
  正确的恢复方式是：移动完成、窗口位置稳定后，通过模拟触发浏览器的全屏操作（比如发送F11按键事件）让应用自身重新进入全屏，而不是手动修改窗口样式硬拉成全屏，这样浏览器会自动更新内部的位置缓存。
• SetWindowPos的标志位使用不当
  目前代码中使用的SWP_FRAMECHANGED标志，会在修改位置时触发窗口边框重算，直接引导浏览器重新执行全屏逻辑，重置窗口位置。配合SWP_NOSIZE标志时，如果窗口还处于全屏切换的过渡状态，尺寸会被锁定为原全屏的满屏尺寸，进一步导致位置计算错误。

修正核心原则 #

所有窗口移动操作，必须先将窗口切换为正常非全屏、非最大化的状态，等待窗口边界完全稳定后再执行位置修改；状态恢复必须通过应用自身的触发机制完成，不要直接修改系统窗口样式硬改状态，避免应用内部的位置缓存不更新。

内容的提问来源于stack exchange，提问作者Kaskorian