Eliminating the Extra Click: Enabling Click‑Through on Inact

If you spend any amount of time on a Mac, you’ve probably noticed that you must activate a window before you can click on any of its controls. The operating system forces you to click the title bar or any empty area of the window, which then brings the window to the foreground and makes it the key window. Only after that can you press a button, check a box, or drag a slider. While this behavior is rooted in macOS’s design philosophy of keeping the focus explicit, it can feel clunky in everyday use.

The Problem in Practice

Imagine you are reviewing a spreadsheet in Numbers, while a Safari window is open with a search bar you need to adjust. To type a new query, you must first click the Safari window, which briefly steals focus from Numbers, then click the address bar, and finally type. That extra click may seem trivial, but when you repeat the pattern dozens of times a day, the cumulative friction becomes noticeable.

Even more puzzling is that the behavior is not uniform across all applications. Some third‑party tools—especially those built on older UI frameworks—allow click‑through: you can interact with a button inside an inactive window directly. Others, like most Apple‑first‑party apps, strictly enforce the activation step. This inconsistency leaves power users searching for a system‑wide solution.

Why There Isn’t a Native Toggle

Apple’s Human Interface Guidelines emphasize that the key window should be the only one receiving keyboard events, and that visual focus should be unmistakable. Changing that default would require a deep modification of the window server, something Apple does not expose publicly. Existing workarounds either involve disabling the entire window manager (which is impractical) or resorting to third‑party utilities that manipulate accessibility APIs.

Enter Hammerspoon: The Lightweight Automation Engine

Hammerspoon is an open‑source automation tool for macOS that bridges Lua scripting with the system’s accessibility and window‑management APIs. It allows developers to write concise scripts that can react to events, modify window properties, and simulate user input. Because Hammerspoon works at the user‑level and leverages officially supported APIs, it provides a safe sandbox for experimentation.

The Core Idea

The solution hinges on a simple observation: when you click inside an inactive window, macOS first sends a mouse‑down event to the window server, which then activates the window. If we intercept that event before the activation step and forward it directly to the UI element under the cursor, the window never needs to become the key window. In other words, we “click through” the activation barrier.

The Script (Explained)

Below is a compact Hammerspoon script that accomplishes this behavior. The code is roughly 30 lines, but the comments make the logic clear.

`lua -- Enable click‑through for inactive windows local clickThrough = hs.eventtap.new({hs.eventtap.event.types.leftMouseDown}, function(e) local win = hs.window.frontmostWindow() if not win then return false end -- If the window under the cursor is not the frontmost one, we intervene local under = hs.window.windowAtPoint(hs.mouse.getAbsolutePosition()) if under and under ~= win then -- Forward the click to the UI element under the cursor hs.eventtap.leftClick(hs.mouse.getAbsolutePosition(), true) -- true = no activation return true -- swallow the original event end return false -- let normal processing continue end) clickThrough:start() `

How it works: 1. Event tap – Hammerspoon creates an event tap that listens for left‑mouse‑down events globally. 2. Window check – It determines the currently frontmost window (frontmostWindow) and the window directly under the cursor (windowAtPoint). 3. Condition – If the cursor is over a different window, the script performs a synthetic left‑click at the same location using hs.eventtap.leftClick. The second argument (true) tells Hammerspoon to not bring the window to the front. 4. Swallow original – Returning true prevents the original click from propagating, effectively replacing it with the click‑through version.

The script respects the user’s normal workflow: clicking on the frontmost window behaves as usual, and the additional logic only triggers when you aim at an inactive one.

Real‑World Benefits

- Reduced Click Count – One click is saved per interaction with an inactive window. Over a typical workday, that can translate to dozens of saved clicks. - Preserved Focus – Your primary task window remains active, preventing accidental keystroke misdirection. - Cross‑Application Consistency – The behavior works uniformly across native Apple apps, third‑party utilities, and even many older Carbon‑based programs. - No System‑Wide Overrides – Because the script runs in user space, there’s no need for kernel extensions or risky system preferences tweaks.

Compatibility and Testing

The author of the original project tested the script on macOS Ventura (13.x) and confirmed it works on the Golden Gate (macOS 14) beta. Hammerspoon itself is regularly updated to stay compatible with the latest macOS releases, so the script should remain functional as long as the underlying accessibility APIs stay stable.

Getting Started

1. Install Hammerspoon – Download the latest release from https://www.hammerspoon.org and place the app in your Applications folder. 2. Enable Accessibility – Open System Settings → Privacy & Security → Accessibility and add Hammerspoon. 3. Create a Config File – Open ~/.hammerspoon/init.lua (create the file if it doesn’t exist) and paste the script above. 4. Reload Config – Click the Hammerspoon menu bar icon and choose Reload Config. 5. Test – Hover over a background window and click a button; you should see the action fire without the window becoming active.

If you encounter edge cases (e.g., certain menus that rely on activation), you can refine the script by adding additional checks for window types or by disabling the tap temporarily via a hotkey.

Contributing and Extending

The original repository on GitHub (dainank/apple-click-through) invites contributions. Possible enhancements include: - Adding a toggle hotkey to enable/disable click‑through on the fly. - Supporting right‑click and middle‑click events. - Introducing per‑application whitelists/blacklists. - Providing visual feedback (e.g., a subtle overlay) when a click‑through occurs.

Because the script is pure Lua, extending it is straightforward for anyone familiar with Hammerspoon’s API.

Final Thoughts

macOS’s requirement to select a window before interacting with its UI is a legacy design decision that can hinder productivity. While Apple does not offer a native switch, the combination of Hammerspoon and a few lines of Lua code delivers a practical, system‑safe workaround. By embracing this lightweight automation, you regain control over your click flow, keep your focus intact, and enjoy a smoother multitasking experience.

Give it a try, share your tweaks, and help the community refine a tool that turns a tiny annoyance into a seamless part of the macOS workflow.

Sources: https://github.com/dainank/apple-click-through