Alt+Tab doesn't switch away from / minimize the app, and F11 windowed-mode toggle has no effect

[dfattal]

Reported by a partner integrator (Amazon Lab126 / LeiaViewer port, internal ticket UNITY-133). This was the 9th item in that report and was missed in the first triage sweep (#261–#268) — filing it now.

Symptom

In a running DisplayXR app:

• Alt+Tab does not switch away from / minimize the app.
• F11 does not toggle windowed mode.

Hypothesis (code-grounded, NOT yet confirmed on hardware)

The provider's weave window is created WS_EX_TOPMOST | WS_EX_NOACTIVATE and tracks Unity's window (native~/displayxr_win32.c ~1245-1265; WS_EX_NOACTIVATE is deliberate so the window never steals OS foreground and Unity's Raw Input keeps flowing). Nothing in that path appears to react to Unity's window losing foreground or being minimized.

If so, both symptoms are the same root cause: the weave window owns what is actually on the panel, and it stays TOPMOST and visible regardless of what happens to Unity's own HWND.

• Alt+Tab moves foreground off Unity, but the topmost weave window keeps painting → looks like the app never switched away.
• Screen.fullScreen (what F11 drives in Samples~/DefaultInputController/DisplayXRInputController.cs:434) toggles Unity's window mode, which the weave window does not follow → F11 appears to do nothing.

What would confirm it

• Does the taskbar/Alt+Tab switcher actually change foreground (i.e. is it purely a visual stickiness), or is input still going to the app?
• Does Screen.fullScreen report the flipped value while the panel output is unchanged?
• Whether this reproduces with DISPLAYXR_PROV_EXTERNAL_WINDOW=1 and in the editor vs a built player.

Likely fix direction

Track the host window's state and mirror it on the weave window: hide/minimize it on WM_ACTIVATEAPP deactivate + SC_MINIMIZE, restore on activate, and follow Unity's windowed/fullscreen transitions. Needs care not to regress the deliberate WS_EX_NOACTIVATE foreground behavior or the #61 drag bracketing.

Note this is window policy, which the plugin has historically treated as app-owned (see the "window-chrome UI is app policy" principle) — but "the app cannot be Alt+Tabbed away from" is a platform-citizenship defect, not a policy choice, so it belongs in the plugin.

[dfattal]

Hypothesis confirmed on hardware (UNITY-133): Alt+Tab does move focus — input lands in the other window — but the app never minimizes and the weave stays painted on top. So it is purely visual stickiness: the WS_EX_TOPMOST weave window keeps covering the screen while the OS has already switched away underneath it.

That narrows the fix to mirroring the host window's visibility state on the weave window (hide/minimize on WM_ACTIVATEAPP deactivate and SC_MINIMIZE, restore on activate), without touching focus behavior — the deliberate WS_EX_NOACTIVATE semantics stay as they are. The F11 half is presumably the same root: Screen.fullScreen toggles Unity's window mode and the weave window doesn't follow.

[dfattal]

Reopening — this was closed by accident, and only half of it is fixed

PR #281's body said Fixes #270, which auto-closed this on merge. That contradicts the PR's own description, the v2.16.0 changelog, and everything I have told the reporter since:

This does NOT close #270. Minimising still fails; a second cause remains and the issue stays open.

My mistake in writing the auto-close keyword. Correcting it here so the remaining half is not lost.

Fixed and hardware-verified (shipped in v2.16.0)

Deactivation. The focus hook suppressed deactivation unconditionally — swallowing WM_ACTIVATEAPP, rewriting WM_ACTIVATE WA_INACTIVE to WA_ACTIVE, and reclaiming focus on WM_KILLFOCUS. Measured before: Application.isFocused never went false across a 28 s session with several Alt+Tabs away. It now suppresses only when the window or thread taking foreground belongs to this process — the overlay case the hook exists for.

Verified in both directions: isFocused flips 9 times where it flipped 0, and keyboard delivery is unaffected (77 keypresses while focused, zero during any unfocused stretch). DXR_AVATAR_FOCUS_HOOK_LEGACY=1 restores the old behaviour.

The intermittent missing-taskbar-button symptom also moved with this change, confirming the two-signature split identified at triage.

Still broken — the reason this stays open

Minimising still fails. A second cause remains and is not identified. What is known:

• The deactivation fix did not move it, so it is not the focus hook's suppression.
• The weave window is WS_EX_TOPMOST and tracks Unity's window, but nothing makes it follow Unity being minimised — it keeps painting over everything.
• Reporter confirmed the failure is visual stickiness rather than input: Alt+Tab does move focus and input lands in the other window, but the app never minimises and the weave stays painted on top.

Open questions, unanswered

• What does a programmatic ShowWindow(hwnd, SW_MINIMIZE) on Unity's main window actually return, and does the overlay follow?
• The overlay's window styles as created — specifically WS_MINIMIZEBOX, WS_EX_TOOLWINDOW, WS_EX_APPWINDOW.
• Is there a SIZE_MINIMIZED case in parent_subclass_proc's WM_SIZE handling? A missing one is a real defect, currently unexercised, and would explain the overlay not following a minimise.
• F11 windowed-mode toggle — same root cause, or a third one? Screen.fullScreen not reaching the overlay was the original hypothesis and it was never tested separately.