Posting this in the beta category after being directed here from Bug Report. The issue was reproduced on beta build 1.60.1.70338, with macOS logs captured during fullscreen and windowed tests.
Environment
- World of Warcraft Beta 1.60.1.70338, classic_beta installation (com.blizzard.worldofwarcraft).
- macOS 27.0.1 (26A434).
- MacBook Pro (Mac14,9), Apple M2 Pro, 32 GB RAM.
- 3 active displays: built-in display plus 2 Dell U2720Q monitors. One Dell is the main display; mirroring is off. Both external displays use a logical 2560 x 1440 resolution at 60 Hz.
- Stage Manager is off.
- Rectangle, Mos, Alfred, Wispr Flow, and iStat Menus were running. I haven’t repeated the tests with those utilities disabled.
Steps to reproduce
- Run WoW in fullscreen mode with other application windows visible on the other monitors.
- Click inside WoW so the game is active.
- Move the pointer to another monitor and click an application window.
- Watch which application becomes active. Repeat with different applications, returning to WoW between attempts.
Expected: The application I click becomes active and keeps focus.
Actual: The clicked application briefly receives focus, then a different application becomes active. I need another click to select the intended application.
Examples from the capture:
- Clicked ChatGPT: Safari became active 135 ms later.
- Clicked Ghostty: Safari became active 114 ms later.
- Clicked Safari: Ghostty became active 118 ms later.
- Clicked Messages: Ghostty became active 157 ms later.
The process labeled ChatGPT in these logs has bundle ID com.openai.codex.
Windowed-mode comparison / workaround
Changing WoW to ordinary Windowed mode avoided the problem in comparable tests across the same applications. The logs confirm those clicks weren’t followed by the delayed focus overrides seen in fullscreen mode. Menu-bar-related focus changes during the display-mode changes themselves are separate from those successful tests.
Technical findings
The macOS unified logs show that the original mouse click activates the correct application through WindowServer’s DoDeferredOrdering path. The second, unwanted activation comes from a SetMenuBars operation on connection 0x5d543.
A read-only SLSConnectionGetPID lookup mapped that connection to Apple’s MenuBarAgent (PID 1332, com.apple.MenuBarAgent). WoW had a different connection, 0x27f337, PID 56857. These IDs apply only to this captured session.
In the Ghostty-to-Safari example, WindowManager also changes the active display again when the unwanted activation occurs. This suggests an interaction between WoW’s fullscreen presentation and macOS menu-bar/display handling. It doesn’t establish whether the underlying defect belongs to Blizzard or Apple.
Recorded on 2026-10-10, with timestamps as shown in the live log:
- 08:55:12.171: Ghostty activated through DoDeferredOrdering.
- 08:55:12.285: MenuBarAgent’s SetMenuBars operation activated Safari.
- 08:58:52.034: Successful windowed Ghostty activation, without the delayed override.
Could the Mac client team investigate the fullscreen deactivation/presentation transition and whether a client-side fix or workaround is possible? I’ve also submitted this to Apple through Feedback Assistant. Targeted logs and the connection-to-process mapping are available if useful.
The first affected game/macOS version is unknown. No clean-utility, addon-isolation, or additional return-to-fullscreen test was performed.