← Back to Blog

Troubleshooting | Jun 9, 2026 | 7 min read

What Is a Click-Through Overlay?

By Mohit Sehrawat

What Is a Click-Through Overlay? — Edge Drop Guide

A clipboard overlay that opens on a screen edge and steals keyboard focus is worse than no overlay at all. You copy a URL, move the cursor to the edge to grab it, the overlay appears — and the moment you click, the target app loses focus, the keyboard lands on the overlay, and the paste you were about to make goes nowhere. The fix is older than Windows 10: a window style flag called WS_EX_NOACTIVATE that tells the OS the window should never receive keyboard activation, even when clicked. This guide explains how click-through edge overlays work on Windows, why focus stealing is the failure mode that matters, and what to check if your overlay is misbehaving.

For neighbouring topics, see startup cost: login-item clipboard apps and taskbar auto-hide versus edge hover zones.

What "no focus steal" actually means

On Windows, every top-level window is either active or inactive. The active window receives keyboard input. When you click a window, the OS sends it a WM_MOUSEACTIVATE message and, by default, activates it — bringing it to the foreground and giving it the keyboard. That is the right default for normal application windows. It is the wrong default for an overlay whose entire purpose is to be a brief staging area between a copy and a paste.

WS_EX_NOACTIVATE is a window extended style that changes this default. A window with this flag is shown, can be hovered, can be clicked, but never becomes the active window. The previously active window retains keyboard focus. This is the flag Windows itself uses for tooltips, for the on-screen keyboard, for the IME candidate window, and for various shell popups that need to be visible without taking over the keyboard.

Why this matters for clipboard overlays

A clipboard overlay's job is to be in the middle of a copy-paste gesture. The user has copied something, wants to retrieve a different item from history, and paste it into the target app. The gesture is:

  1. Copy (target app has focus).
  2. Move cursor to edge (overlay appears).
  3. Click the desired history item (overlay must NOT take focus).
  4. The overlay hands the item to the clipboard.
  5. Paste into the target app (target app must still have focus).

If step 3 activates the overlay, then step 5 fails — the paste goes into the overlay, which has no paste handler, and the user is left clicking back into the target app and pasting again. The overlay has broken the gesture it was supposed to accelerate.

The same problem affects drag-out workflows. If the overlay steals focus on mouse-down, the drag source is the overlay rather than the target app, and certain OLE drop targets behave differently when the drag source is not the same process as the active window.

What can go wrong

WS_EX_NOACTIVATE is necessary but not sufficient. Several secondary failure modes remain:

  • The overlay window is shown with SetForegroundWindow. Calling SetForegroundWindow on a WS_EX_NOACTIVATE window does not steal focus, but it does bring the window to the top of the z-order in a way that can confuse the focus restoration logic of some target apps. The correct call is SetWindowPos with SWP_NOACTIVATE.
  • The overlay plays an animation that involves ShowWindow(SW_SHOWNORMAL). Some show-window commands implicitly activate. Use SW_SHOWNOACTIVATE or SW_SHOWNA instead.
  • The overlay's child controls steal focus on mouse-down. Even if the top-level window has WS_EX_NOACTIVATE, a button inside it can still call SetFocus on itself when clicked. The fix is to handle WM_MOUSEACTIVATE and return MA_NOACTIVATE for the entire window tree.
  • The overlay is dismissed by clicking elsewhere, which activates the click target. That is correct behaviour — clicking elsewhere should activate the click target — but if the overlay is dismissed by a global hotkey, the hotkey handler must not call SetForegroundWindow.

How to test focus behaviour

A simple test verifies the property end-to-end:

  1. Open Notepad. Type a few characters; the cursor should be blinking in Notepad.
  2. Open the overlay (cursor into the edge hot zone, or press its hotkey).
  3. Click an item in the overlay.
  4. Without clicking anywhere else, press Ctrl+V.

If the paste lands in Notepad, the overlay is correctly non-activating. If the paste does nothing, or if a caret is not visible in Notepad, the overlay stole focus at step 3.

A second test, for drag-out:

  1. Open a File Explorer window.
  2. Open the overlay.
  3. Drag a file item from the overlay into the Explorer window.
  4. Release.

If the file lands in Explorer and the previously selected folder is still selected, the overlay handled drag correctly. If Explorer flickers or the selection changes, the overlay is likely calling SetForegroundWindow on drag start.

Click-through behaviour

A related property is click-through: the ability of the overlay, when collapsed, to be transparent to mouse input so that clicks pass through to whatever is behind it. This is implemented with WS_EX_TRANSPARENT combined with WS_EX_LAYERED. The combination tells the OS that the window is for display only and should not receive mouse messages; clicks pass through to the window below.

When the overlay opens, the transparent flag is removed so that the overlay can receive clicks. When it closes, the flag is restored so that the edge does not block normal use of the screen area. The transition must be atomic — if the overlay removes the transparent flag too early, it can swallow a click intended for the window behind it.

This is the pattern Edge-Drop, the Windows hover-activated clipboard shelf, uses: a frameless, transparent, always-on-top window that is click-through when collapsed and interactive when opened. The shelf's WS_EX_NOACTIVATE flag is what makes click-to-paste work without stealing keyboard focus from the target app. The same pattern is used by various Windows shell overlays and is well-documented in the Win32 reference.

Comparing to other approaches

There are three common approaches to a clipboard overlay on Windows, with different focus trade-offs:

ApproachFocus behaviourWhen it worksWhen it fails
Standard top-level windowSteals focus on clickModal dialogs, settings windowsClipboard overlays, drag-out shelves
WS_EX_NOACTIVATE top-levelNever steals focusTooltips, clipboard overlays, IMEAnything that needs keyboard input
WS_EX_TRANSPARENT + WS_EX_LAYEREDClicks pass throughHidden trigger zones, watermarksInteractive overlays

The right answer for a clipboard overlay is the combination: WS_EX_NOACTIVATE for the open state, plus WS_EX_TRANSPARENT | WS_EX_LAYERED for the collapsed state. The two flags solve different problems and both are needed.

For a deeper comparison of clipboard overlay approaches, see clipboard tools on multi-monitor Windows setups and always-on-top apps that fight each other.

What this does not solve

WS_EX_NOACTIVATE keeps the overlay out of the keyboard focus. It does not:

  • Protect against UAC elevation prompts. If the target app is running elevated and the overlay is not, the overlay cannot paste into the target app regardless of focus. See the UAC discussion in Win+V not working on Windows 11: 9 fixes.
  • Make the overlay work in fullscreen exclusive games. Fullscreen exclusive mode directs all input to the game; the overlay is not visible at all. The correct behaviour is to suppress the overlay entirely in fullscreen; see gaming fullscreen and clipboard hotkeys.
  • Solve the "two clipboard managers conflict" problem. Two managers running simultaneously will both watch the clipboard and both modify it on paste, producing duplicates or lost items.

Honest positioning

Edge-Drop's claim to a click-through, non-activating edge overlay is genuine — it is one of the few Windows clipboard tools built around the WS_EX_NOACTIVATE pattern from the start, rather than retrofitting it onto a tray-popup design. That said, this property is not unique to Edge-Drop; several other Windows overlay utilities use the same Win32 flags. The shelf does not win on RAM, scripting, or capture, and it should not be expected to. What it offers is the spatial gesture — hover the edge, drag out, paste into the target without losing focus. Whether that gesture is worth the Electron overhead is a per-user decision.

A short checklist

If your clipboard overlay is breaking paste gestures, check in this order:

  1. Does the overlay use WS_EX_NOACTIVATE? (Look for SetWindowPos with SWP_NOACTIVATE in the code, or test with the Notepad paste test above.)
  2. Does the overlay handle WM_MOUSEACTIVATE and return MA_NOACTIVATE for child controls?
  3. Does the overlay use SW_SHOWNOACTIVATE / SW_SHOWNA rather than SW_SHOWNORMAL?
  4. When collapsed, is the overlay WS_EX_TRANSPARENT so clicks pass through?
  5. Does the overlay's drag-out use OLE drag-and-drop with IDropSource, rather than calling SetForegroundWindow on drag start?

A "yes" to all five is the right answer. A "no" to any of them is the cause of the focus-steal symptom.

Related reading

Sources

Mohit Sehrawat
Written by Mohit Sehrawat · Author & Software Tester

Mohit Sehrawat is a B.Tech Computer Science Engineering student with a focus on software testing, bug detection, and product quality. He is interested in exploring applications, identifying issues, and improving the overall user experience through thorough testing.

GitHub · LinkedIn

Copy. Stack. Drop.

Transform your clipboard into an interactive edge shelf. Stack, pin, and drag assets into any app with zero friction.

Download for Windows Get from Microsoft Store

How to Install Guide · First 10 Minutes Guide · Drag & Drop Guide · Edge-Drop vs Win+V · Support

Free · Lightweight · Privacy First
Find us on CodeHype