# Windows: title-bar click no longer raises the window (8.0.2), and owned transparent windows get offset by their owner

**URL:** <https://forum.juce.com/t/windows-title-bar-click-no-longer-raises-the-window-8-0-2-and-owned-transparent-windows-get-offset-by-their-owner/69520>\
**Category:** General JUCE discussion\
**Created:** [September 14, 2026, 7:00pm UTC](https://forum.juce.com/t/windows-title-bar-click-no-longer-raises-the-window-8-0-2-and-owned-transparent-windows-get-offset-by-their-owner/69520 "2026-09-14T19:00:22Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Toddler-Boy](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/toddler-boy/32/2007_2.png) [@Toddler-Boy](https://forum.juce.com/u/Toddler-Boy)\
**Post date:** [September 14, 2026, 7:00pm UTC](https://forum.juce.com/t/windows-title-bar-click-no-longer-raises-the-window-8-0-2-and-owned-transparent-windows-get-offset-by-their-owner/69520/1 "2026-09-14T19:00:22Z")

</div>

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:

```auto
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](https://forum.juce.com/uploads/short-url/nWfNgtHq8b36PvGgLguFvE3quYe.patch) (1.1 KB)  
[0002-owned-window-bounds.patch](https://forum.juce.com/uploads/short-url/mKwrarvHwRn6Q2rS2h8pBcVoJpC.patch) (871 Bytes)

---

<div class="post-metadata">

**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\
**Post date:** [September 18, 2026, 12:19pm UTC](https://forum.juce.com/t/windows-title-bar-click-no-longer-raises-the-window-8-0-2-and-owned-transparent-windows-get-offset-by-their-owner/69520/2 "2026-09-18T12:19:25Z")

</div>

Thanks, the titlebar issue is fixed here:

> <https://github.com/juce-framework/JUCE/commit/1c66556aedb2a801854ec972f2a26ebd1db0ccbd>

And, the issue with parent/child positioning is fixed here:

> <https://github.com/juce-framework/JUCE/commit/a6da1b4364228954cb04296b628e830cae488636>
>
> As part of this change, uses of GetParent have been switched to
> GetAncestor(...,… GA\_PARENT). In cases where this function was called,
> we were attempting to find the parent window, rather than a non-parent
> owner window.

---

<div class="post-metadata">

**Author:** ![Toddler-Boy](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/toddler-boy/32/2007_2.png) [@Toddler-Boy](https://forum.juce.com/u/Toddler-Boy)\
**Post date:** [September 18, 2026, 4:03pm UTC](https://forum.juce.com/t/windows-title-bar-click-no-longer-raises-the-window-8-0-2-and-owned-transparent-windows-get-offset-by-their-owner/69520/3 "2026-09-18T16:03:24Z")

</div>

Thank you. Both issues are fixed.