Two issues in the Windows peer, both with small patches attached. Tested on develop as of September 2026, Windows 11.
1. A plain title-bar click activates the window but doesn’t raise it
Since 8.0.2, onNcLButtonDown handles HTCAPTION by storing the click and returning 0, and only hands it to DefWindowProc once the mouse moves with the button held (the comment says this keeps the view painting during the click). The side effect: DefWindowProc’s caption handling is also what brings the window to the top of the z-order. With a native title bar, clicking the title bar of a JUCE window that sits behind another application now activates it (WM_ACTIVATE arrives, broughtToFront() fires) but leaves it behind the other window until the mouse moves by a pixel. Every other application raises on the click.
It also interacts with the deferred focus update in WM_SETFOCUS: after a mouse activation JUCE waits for the next client-area mouse event before calling handleSetFocus(). A title-bar click never produces one, so after a title-bar activation no component holds the keyboard focus until the user clicks inside the window. Keyboard shortcuts go nowhere in the meantime.
Repro: any DocumentWindow with a native title bar. Put another app’s window over part of it, click the visible part of the JUCE title bar, don’t move the mouse.
Patch 0001 simply lets the caption click fall through to DefWindowProc again (the 8.0.1 behaviour). If the repaint-during-click behaviour is worth keeping, an alternative is to raise the window explicitly in the HTCAPTION case and keep the deferral for the drag.
2. setBoundsPhysical treats an owner as a parent for per-pixel-transparent windows
In HWNDComponentPeer::setBoundsPhysical, the per-pixel-transparent branch does:
if (auto parentHwnd = GetParent (hwnd))
{
const auto parentRect = ...getWindowScreenRect (parentHwnd)...;
newBounds += parentRect.getPosition();
}
GetParent returns the owner for an owned top-level window, not only the parent of a child window (documented Win32 behaviour). An owned popup window (a WS_POPUP peer given an owner via GWLP_HWNDPARENT, the standard way to keep a floating panel above its main window without making it topmost) has screen coordinates, so every setBounds lands at “requested position plus owner position”. Move the main window and the popup drifts away from it at a different speed. getBounds() right above already distinguishes the cases via the parentToAddTo member, so the fix is to use the same member here (patch 0002).
Motivation, in case it helps: a transient popup panel (own transparent desktop window with a drop shadow) that must stay above the main window whichever of the two is active, but must not float over other applications. Always-on-top does the former and breaks the latter, an owned window does both, and it works fine with patch 0002.
0001-caption-click-goes-to-DefWindowProc.patch (1.1 KB)
0002-owned-window-bounds.patch (871 Bytes)