[admin-toolkit] Toolkit close (×) button does not fire on click; only F1 closes the panel #13

New issue

Closed

opened 2026-10-06 22:41:50 +00:00 by Mark · 1 comment

Mark commented

2026-10-06 22:41:50 +00:00

Owner

Summary

The Creation Toolkit's title-bar close button (×) at the top-right corner of the window does not fire when clicked. Only the F1 keybinding (which the button's own tooltip advertises: "Close (F1)") reliably closes the panel. Clicks land on the button's general area but the pressed signal never fires.

Environment

Repo: Mark/veilwalkers
Build: debug (Godot 4.7.2)
Driven by: Computer Use MCP click and hand-click on a touchpad
Same session as Issue #12 (admin toolkit open, world hosted, 400/400 population)

Steps to Reproduce

Open the Veilwalkers — Creation Toolkit (F1 or click the Toolkit button at the bottom).
Move the mouse cursor over the × in the title bar at the top-right of the toolkit window.
Click the × button.

Expected

The toolkit panel should close (its visibility flips off). Same behavior as pressing F1.

Actual

Nothing happens. The toolkit stays open. The click does reach the panel — moving the cursor over the button shows the hover state (cursor changes / button background lightens) — but pressed is not emitted. The same click coordinates sometimes instead activate the World tab (which sits below the title bar in the panel layout), confirming the click is reaching the panel's Control hierarchy but missing the close Button's hitbox specifically.

Repro Coordinates

Within the 1280×720 Godot window, the close (×) was at approximately (810, 30) in window-relative pixels. That position is inside the panel's title bar visually but does not register as a hit on the close Button instance. World tab is at (263, 78) and the (×) being at (810, 30) means there's a wide X distance between the two — yet clicks near (810, 30) sometimes activate the World tab, suggesting the panel's internal layout is shifted or the title bar's hitbox is too tall and is funneling clicks into the TabContainer underneath.

Why This Matters

The user's documented close path (the visible ×) is broken. F1 still works, but the only "discoverable" close affordance is non-functional.
This is a regression in the "obviously visible UI control fires obvious action" expectation. The X position is the universal close affordance for floating panels.

Suggested Investigation Path

Inspect scenes/admin/admin_toolkit.gd _build_title_bar() — confirm the close Button's mouse_filter is MOUSE_FILTER_STOP (not MOUSE_FILTER_PASS or MOUSE_FILTER_IGNORE).
Confirm the close.pressed.connect(toggle) is firing by adding a print("close pressed") in the toggle function.
Compare the title bar's actual rect against where the X is rendered. The PanelContainer may be clipping or the close button may be mispositioned by a few pixels.
Verify the title bar's gui_input.connect(_on_title_gui_input) drag handler isn't eating the click on the close button. The drag handler fires on InputEventMouseButton; if the close button is a child of the title bar, the close's pressed signal should still fire — but if the title bar uses MOUSE_FILTER_PASS or the close's mouse_filter is wrong, the click can be lost.

Workaround (until fixed)

Press F1 to close the toolkit. F1 still works reliably.

## Summary The Creation Toolkit's title-bar close button (×) at the top-right corner of the window **does not fire when clicked**. Only the **F1** keybinding (which the button's own tooltip advertises: "Close (F1)") reliably closes the panel. Clicks land on the button's general area but the `pressed` signal never fires. ## Environment - Repo: `Mark/veilwalkers` - Build: debug (Godot 4.7.2) - Driven by: Computer Use MCP `click` and hand-click on a touchpad - Same session as Issue #12 (admin toolkit open, world hosted, 400/400 population) ## Steps to Reproduce 1. Open the Veilwalkers — Creation Toolkit (F1 or click the **Toolkit** button at the bottom). 2. Move the mouse cursor over the **×** in the title bar at the top-right of the toolkit window. 3. Click the **×** button. ## Expected The toolkit panel should close (its visibility flips off). Same behavior as pressing F1. ## Actual Nothing happens. The toolkit stays open. The click does reach the panel — moving the cursor over the button shows the hover state (cursor changes / button background lightens) — but `pressed` is not emitted. The same click coordinates sometimes instead activate the **World** tab (which sits below the title bar in the panel layout), confirming the click is reaching the panel's Control hierarchy but missing the close Button's hitbox specifically. ## Repro Coordinates Within the 1280×720 Godot window, the close (×) was at approximately **(810, 30)** in window-relative pixels. That position is *inside* the panel's title bar visually but does not register as a hit on the `close` Button instance. World tab is at (263, 78) and the (×) being at (810, 30) means there's a wide X distance between the two — yet clicks near (810, 30) sometimes activate the World tab, suggesting the panel's internal layout is shifted or the title bar's hitbox is too tall and is funneling clicks into the TabContainer underneath. ## Why This Matters - The user's documented close path (the visible ×) is broken. F1 still works, but the only "discoverable" close affordance is non-functional. - This is a regression in the "obviously visible UI control fires obvious action" expectation. The X position is the universal close affordance for floating panels. ## Suggested Investigation Path 1. Inspect `scenes/admin/admin_toolkit.gd` `_build_title_bar()` — confirm the `close` Button's `mouse_filter` is `MOUSE_FILTER_STOP` (not `MOUSE_FILTER_PASS` or `MOUSE_FILTER_IGNORE`). 2. Confirm the `close.pressed.connect(toggle)` is firing by adding a `print("close pressed")` in the toggle function. 3. Compare the title bar's actual rect against where the X is rendered. The `PanelContainer` may be clipping or the close button may be mispositioned by a few pixels. 4. Verify the title bar's `gui_input.connect(_on_title_gui_input)` drag handler isn't eating the click on the close button. The drag handler fires on `InputEventMouseButton`; if the close button is a child of the title bar, the close's `pressed` signal should still fire — but if the title bar uses `MOUSE_FILTER_PASS` or the close's `mouse_filter` is wrong, the click can be lost. ## Workaround (until fixed) Press **F1** to close the toolkit. F1 still works reliably.

Mark added the

bug

triage-approved

labels

2026-10-06 22:41:50 +00:00

Mark referenced this issue from a commit

2026-10-06 22:46:38 +00:00

fix(admin-toolkit): close (×) button now fires on click (#13)

Mark commented

2026-10-06 22:47:15 +00:00

Author

Owner

Fixed in 90c7438 on main. Root cause: the title bar PanelContainer's gui_input drag handler was initiating a tiny drag between press and release on close-button clicks, shifting the window off the button before the Button's release could emit pressed. Fix: skip drag-start when the press lands inside the close button's hitbox, give the close button a 32x32 minimum size and explicit STOP mouse_filter, and reference it via a member variable. F1 path unchanged. gdlint + gdformat clean.

Fixed in 90c7438 on main. Root cause: the title bar PanelContainer's `gui_input` drag handler was initiating a tiny drag between press and release on close-button clicks, shifting the window off the button before the Button's release could emit `pressed`. Fix: skip drag-start when the press lands inside the close button's hitbox, give the close button a 32x32 minimum size and explicit STOP mouse_filter, and reference it via a member variable. F1 path unchanged. gdlint + gdformat clean.

Mark closed this issue

2026-10-06 22:47:23 +00:00