Invisible region below menu bar on external display blocks all clicks/hover, even with a minimal single-display bar (v2.24.0)

Summary

With a bottom-positioned bar restricted to the built-in display via display=main, a fixed-location rectangular region directly under the system menu bar on a separate, non-top-aligned external display stops receiving all mouse input — not just clicks, but hover/mouseover events too (e.g. browser toolbar buttons, bookmarks bar, and page content don't highlight or respond at all). The affected app window itself is otherwise unaffected outside that region. Quitting SketchyBar entirely immediately restores normal input in that area; hiding the bar (sketchybar --bar hidden=on) does not restore it.

Environment

• SketchyBar 2.24.0 ("Rendering System Overhaul"), installed via Homebrew
• Apple Silicon MacBook Pro, built-in Liquid Retina display (3024x1964 physical / reported as 1352x878 pt via sketchybar --query displays)
• One external display (1920x1080), connected via extended desktop
• sketchybar --query displays showed the external display's frame as {"x":1352,"y":-117,"w":1920,"h":1080} — i.e. not top-aligned with the built-in display (vertical arrangement offset of -117pt)
• "Displays have separate Spaces" enabled (default)

Repro steps

1. Arrange an external display so it is not top-aligned with the built-in display (e.g. drag it slightly up or down in System Settings → Displays → Arrangement).
2. Run a minimal config:

sketchybar --bar display=1 position=bottom height=32 color=0xff000000
sketchybar --update

(No items, no event subscriptions — display=1 is the built-in display's arrangement id.) 3. Open any window on the external display, positioned near the top (so its toolbar sits directly under that display's own menu bar — each display gets its own menu bar since "Displays have separate Spaces" is on). 4. Try to click or even just hover over UI elements in a horizontal band directly beneath the menu bar on the external display (e.g. window traffic lights, toolbar buttons, bookmarks bar). These do not respond at all, as if another window is intercepting all mouse events there. 5. Quit SketchyBar completely → the region immediately becomes responsive again. 6. sketchybar --bar hidden=on → issue persists (rules out the visible bar drawing/hit-testing). 7. sketchybar --query <item> bounding_rects only ever report a display-1 entry (the built-in display) even while the problem is occurring on display 2 — the affected region isn't visible through the public query interface at all.

Workaround found

Re-aligning the external display so its top edge is flush (zero vertical offset) with the built-in display's top edge in System Settings → Displays resolved the issue completely, with the exact same SketchyBar config.

Suspected cause

Given the bar's default window level is kCGBackstopMenuLevel (tied to per-display menu bar geometry) and this only manifested on a display with a non-zero vertical arrangement offset, this looks related to the per-display "menu bar inset" calculation touched by #810 (merged into this same 2.24.0 release) — possibly an edge case in that calculation (or a related one) that isn't fully covered when a secondary display isn't top-aligned with the display SketchyBar computes offsets relative to. The fact that the blocked area affects hover as well as clicks suggests the window server is treating that whole region as reserved menu-bar territory rather than SketchyBar mis-routing click coordinates.

Happy to provide more diagnostic output (full sketchybarrc, --query bar/--query displays dumps, etc.) if useful — this took a fair amount of isolation to pin down since it reproduces even with zero items/events and only affects a display the bar isn't even configured to render on.