yabai 项目中关于窗口查询异常的技术分析

问题背景

在 macOS 窗口管理工具 yabai 的使用过程中，发现了一个关于窗口查询的异常现象。当使用 yabai -m query --windows --space X 命令查询特定空间的窗口时，会返回一些实际上并不属于该空间的窗口对象。这种情况主要出现在 Microsoft Teams 和 Outlook 等微软系应用程序的某些特殊窗口上。

现象描述

通过命令行查询空间4的窗口时，返回的结果中包含了实际位于空间7的两个 Microsoft Teams 窗口。这两个窗口具有以下特征：

1. 窗口标题分别为"Sharing Indicator"和"Sharing control bar | Microsoft Teams"
2. 窗口子角色(subrole)为"AXSystemDialog"
3. 窗口层级(level)异常高(2147483631和24)
4. 窗口框架(frame)覆盖整个屏幕或部分区域

技术原因分析

这种现象的根本原因在于 macOS 系统本身的窗口管理机制。yabai 在查询窗口时，实际上是调用了 macOS 的原生 API：

CFArrayRef window_list_ref = SLSCopyWindowsWithOptionsAndTags(g_connection, cid, space_list_ref, options, &set_tags, &clear_tags);

微软应用程序的这些特殊窗口设置了特殊的集合行为(Collection Behavior)和窗口样式掩码(StyleMask)。具体表现为：

1. 这些窗口可能设置了 NSWindowCollectionBehaviorCanJoinAllSpaces 标志，使其能够出现在所有空间中
2. 作为系统对话框(AXSystemDialog)，它们具有特殊的显示优先级
3. 异常高的窗口层级表明它们需要保持在最前端显示

解决方案

在 yabai 的最新主分支中，已经对这些窗口做了特殊处理，将它们标记为"粘性窗口"(is-sticky: true)。用户可以通过以下方式处理这些窗口：

1. 使用 jq 工具进行二次过滤：

yabai -m query --windows --space 4 | jq -r ".[] | select (.space == 4)"

2. 检查窗口的 is-sticky 属性并过滤掉粘性窗口

3. 等待包含此修复的正式版本发布

最佳实践建议

对于开发者和高级用户，在处理窗口查询结果时，建议：

1. 始终验证窗口的 space 属性是否与查询条件匹配
2. 对特殊子角色(AXSystemDialog等)的窗口进行特别处理
3. 注意检查窗口的 collection behavior 相关属性
4. 考虑窗口的 level 和 sub-level 属性对显示行为的影响

这种设计实际上是 macOS 系统的一种特性而非缺陷，它允许某些需要全局可见的系统窗口(如屏幕共享指示器、输入法等)能够跨越空间边界显示。yabai 作为窗口管理工具，需要在这种系统特性和用户期望之间找到平衡点。