Describe the bug
A mismatch in ClickThrough settings makes the menu bar items, even system defaults like the control center, unclickable. This is a bug I see infrequently with the Floating Window Menu Statusbar preset, but when it happens, even quitting & restarting BTT doesn’t fix it. Finally it happened when I thought to ask AI about it & it suggested a fix & wrote up this report.
Affected input device: macbook mouse & menu
Device information:
-
Type of Mac:MacBook Pro 14” 2023
-
macOS version: 26.4.1
-
BetterTouchTool version: 6.396
Additional information: AI Generated
Floating Menu with ClickThroughEverywhere=1 Still Blocks Clicks — Fix Found
Summary
If you're using a transparent floating menu as an invisible hover-detection overlay (e.g. to detect when the mouse enters the menubar area), you may find that it blocks clicks on whatever is underneath — even when BTTMenuClickThroughEverywhere is set to 1.
The Setup
I have a floating menu called "HoverRecognitionOverlay" that acts as an invisible sensor strip across the top of the screen. Its job is to detect hover events over the system menubar and trigger show/hide of a second floating menu (a custom status-item bar). Key properties:
-
Window level: Very high (above the system menubar)
-
Background type: 0 (none) — visually transparent
-
Size: ~600×24 px strip at the top of the screen
-
Resize on hover: Enabled (expands when the mouse enters)
-
BTTMenuClickThroughEverywhere: 1 (enabled) -
BTTMenuClickThroughEmptyParts: 0 (disabled)
With this configuration, all clicks on the system menubar (clock, Control Center, Wi-Fi, etc.) were being swallowed. Disabling the overlay restored normal clicking. The hover detection itself worked fine — only clicks were blocked.
Root Cause
The issue is the combination of two properties:
| Property | Value | Effect |
| BTTMenuClickThroughEverywhere | 1 | Should pass all clicks through |
| BTTMenuClickThroughEmptyParts | 0 | Do NOT pass clicks through empty areas |
Since the overlay is entirely "empty space" (no visible items, no background), the entire surface area is classified as "empty parts." The more-specific ClickThroughEmptyParts: 0 appears to take precedence over the general ClickThroughEverywhere: 1, causing the overlay to intercept all clicks despite the global click-through being enabled.
The Fix
Set BTTMenuClickThroughEmptyParts to 1:
BTTMenuClickThroughEmptyParts: 1
BTTMenuClickThroughEverywhere: 1
After this change, clicks pass through to the system menubar correctly, and hover detection continues to work as expected.
Additional Fix — Phantom Visible Action Items
In my case, the overlay also had a hover-start action (a "Show Floating Menu" action with BTTActionCategory: 1) that had its own BTTMenuConfig with:
BTTMenuItemVisibleWhileActive: 1
BTTMenuItemVisibleWhileInactive: 1
This action had no explicit size constraints, meaning it could render as a zero-size but still "visible" element that intercepts mouse events. Setting both visibility properties to 0 eliminated this as a secondary click-blocking surface.
Possible Bug / Feature Request
It seems like BTTMenuClickThroughEverywhere: 1 should be an override that makes the entire menu click-through regardless of other settings. Currently, BTTMenuClickThroughEmptyParts: 0 can override it for empty areas, which is counterintuitive — if "everywhere" is enabled, "empty parts" should be included in "everywhere."
Suggested behavior: When BTTMenuClickThroughEverywhere is 1, ignore BTTMenuClickThroughEmptyParts entirely.