Wayland通过“XDG Activation”机制有效防止窗口焦点被窃取，提升了用户体验和安全性。当用户双击文件时，文件管理器会向Wayland合成器请求一次性激活令牌，PDF查看器启动后需出示该令牌才能获得焦点。若令牌无效，窗口图标会闪烁以提醒用户。KDE开发者计划在KWin中全面实施此机制，相比X11的基于时间戳的脆弱系统，Wayland的焦点管理更为可靠。

Wayland在处理窗口焦点方面与X11有着显著的不同，其核心优势在于通过“XDG Activation”协议有效防止焦点窃取问题。以下是其工作原理的简要说明：

当用户在文件管理器中双击一个PDF文件时，文件管理器会向Wayland合成器请求一个一次性的“激活令牌”，该请求与用户的点击行为直接关联，证明这是用户主动触发的操作。随后，文件管理器启动PDF阅读器并将令牌传递给它。PDF阅读器在启动时向合成器展示该令牌并请求激活。合成器验证令牌的有效性，若合法则赋予PDF阅读器焦点。如果令牌缺失、过期或无效，合成器会拒绝请求，PDF阅读器窗口不会获得焦点，而是通过任务栏图标闪烁来吸引用户注意。

KDE开发者Kai-Uwe Broulik最近提到，计划在KWin（KDE Plasma的窗口管理器）中低级别地启用Wayland的焦点窃取防护机制。在X11系统中，新窗口或对话框只能在应用程序最近处于活动状态时获取焦点，这一检查通常基于一个名为NETWMUSERTIME的时间戳，但该系统并不完善。例如，X11的防护逻辑有时会阻止Adobe Flash Player的全屏窗口显示在YouTube视频之上。在X11中，应用程序可以调用XSetInputFocus来窃取其他应用的焦点，尽管KWin会尝试纠正，但焦点仍会短暂闪烁。

在Wayland中，XDG Activation协议使得情况大为改善，但仍有部分应用程序因不当使用而违反协议。默认情况下，KWin会为任何新打开的窗口赋予焦点，但这一行为正在改变。在窗口管理设置中新增的“焦点窃取防护”的“极端”模式将强制KWin仅在窗口使用有效令牌请求激活时才赋予其焦点。

通过这一更严格的模式，开发者Xaver Hugl和Kai-Uwe Broulik已经修复了大量问题，并引入了多项关键改进：

• Dolphin在启动新实例时不再丢弃其激活令牌。
• KRunner、Kickoff和其他Plasmoid弹出窗口现在能正确请求激活。
• LayerShell-Qt在显示时请求激活，并正确读取环境中的XDGACTIVATIONTOKEN。
• 允许像Plasma这样的特权客户端正确请求令牌。
• 忽略修饰键按下事件，因为它们通常是全局快捷键的一部分。

此外，后端工作也有所进展，DBusRunner规范新增了SetActivationToken方法，该方法在操作运行前被调用。桌面搜索工具Baloo现在使用此方法确保在现有应用程序窗口中打开文件时能正常工作。

更多详情可参考Kai的博客文章。

评论内容主要围绕“焦点窃取”（focus stealing）问题展开，以下是主要观点和论据的总结：

1. 支持严格限制焦点窃取

• 主要观点：用户希望操作系统或桌面环境能够严格限制应用程序窃取焦点，只有在用户明确操作时才允许焦点切换。
• 论据：
  • rollcat：焦点切换应仅限于用户明确操作，如启动应用、点击窗口或使用快捷键，其他情况都应视为“邪恶”。
    引用： "The only conditions under which focus should change: I’ve just launched the application, I’ve clicked on a window..."
  • Shank：焦点窃取问题在2025年仍然存在，用户希望在不被打扰的情况下使用电脑。
    引用： "I want to use my computer without random popups accidentally eating my keyboard commands..."

2. 对焦点窃取问题的不同体验

• 主要观点：部分用户认为焦点窃取问题并不普遍，甚至从未遇到过。
• 论据：
  • jm4：作为长期Linux用户，使用KDE和Wayland，从未意识到焦点窃取问题。
    引用： "Is focus stealing a real problem? I wasn’t even aware this was a thing."
  • whalesalad：更多时候遇到的是应用无法获取焦点，导致操作不便。
    引用： "I only experience the opposite - frustration that something I expect to become the new focus, front-and-center window, is not."

3. 对现有解决方案的批评

• 主要观点：现有解决方案（如任务栏闪烁）并不理想，甚至可能带来新的困扰。
• 论据：
  • eviks：任务栏闪烁是一种糟糕的替代方案，不应频繁使用。
    引用： "This is just a common awful alternative. There is nothing important about this activity to flash..."
  • bjoli：Gnome的上下文菜单窃取焦点问题仍未解决，影响用户体验。
    引用： "I still have problems with context menus stealing focus and locking it to the window where they are opened."

4. 对其他操作系统的期望

• 主要观点：用户希望macOS和Windows等主流操作系统也能解决焦点窃取问题。
• 论据：
  • ghusto：iPad的“勿扰模式”更有效，因为应用无法绕过系统限制。
    引用： "DnD on iPad/iPhone actually does what it says on the tin, because applications can’t bypass it..."
  • rpgbr：macOS在Safari中的右键菜单行为改变，导致焦点丢失。
    引用： "The context menu shows up and previous foreground app loses focus, but Safari doesn’t get it/stays in background..."

5. 技术实现建议

• 主要观点：焦点切换应由窗口管理器控制，而非应用程序自行请求。
• 论据：
  • nottorp：焦点切换应仅由窗口管理器基于用户操作进行。
    引用： "Can’t you just not allow applications to request focus from themselves, and allow focus changes only from the window manager based on user actions?"
  • eviks：现有的令牌机制还不够完善，长时间操作可能导致焦点被窃取。
    引用： "Doesn’t seem to go far enough. If this is a long operation and you switch to another app to read a page in a browser, will the opened PDF steal focus from your reading?"

总结：

评论中，用户对焦点窃取问题表达了不同的看法和体验。支持严格限制焦点窃取的用户认为，焦点切换应仅由用户明确操作触发，而部分用户则表示从未遇到过该问题，甚至更多时候遇到的是应用无法获取焦点的困扰。现有解决方案（如任务栏闪烁）被认为不够理想，用户希望macOS和Windows等主流操作系统也能解决这一问题。技术实现上，焦点切换应由窗口管理器控制，而非应用程序自行请求。