Problem
On Windows, closing an attached modal can activate another application's window instead of returning activation to the modal owner. The owner remains visible, but moves behind the unrelated foreground window.
AttachModal disables the owner with EnableWindow(owner, false). The current WM_CLOSE path re-enables it after DefWindowProc has already destroyed the active modal. Re-enabling the owner before destruction is necessary, but is not enough by itself: Windows may still activate the next top-level window in the Alt+Esc order rather than the owner.
Fix
Before shutting down the modal WebView, record whether the modal is the foreground window. Re-enable its owner before destroying the modal, and if the modal was foreground, call SetActiveWindow(owner) first. This keeps the owner active when closing a foreground modal without stealing focus when the modal is already in the background.
This sequence was tested in a downstream Wails application and fixed the foreground/Z-order regression.
Problem
On Windows, closing an attached modal can activate another application's window instead of returning activation to the modal owner. The owner remains visible, but moves behind the unrelated foreground window.
AttachModaldisables the owner withEnableWindow(owner, false). The currentWM_CLOSEpath re-enables it afterDefWindowProchas already destroyed the active modal. Re-enabling the owner before destruction is necessary, but is not enough by itself: Windows may still activate the next top-level window in the Alt+Esc order rather than the owner.Fix
Before shutting down the modal WebView, record whether the modal is the foreground window. Re-enable its owner before destroying the modal, and if the modal was foreground, call
SetActiveWindow(owner)first. This keeps the owner active when closing a foreground modal without stealing focus when the modal is already in the background.This sequence was tested in a downstream Wails application and fixed the foreground/Z-order regression.