Skip to content

debugui: don't let a collapsed window capture clicks on its hidden body - #56

Closed
iamhuman-cheolheelee wants to merge 1 commit into
ebitengine:mainfrom
iamhuman-cheolheelee:fix/collapsed-window-hover
Closed

iamhuman-cheolheelee wants to merge 1 commit into
ebitengine:mainfrom
iamhuman-cheolheelee:fix/collapsed-window-hover

Conversation

@iamhuman-cheolheelee

@iamhuman-cheolheelee iamhuman-cheolheelee commented Sep 26, 2026 •

Copy link
Copy Markdown

What issue is this addressing?

Closes #55

What type of issue is this addressing?

bug

What this PR does | solves

Root cause

hoveringRootContainer (container.go:370) hit-tests root containers against cnt.layout.Bounds regardless of cnt.collapsed. A collapsed window on top therefore still owns its whole (invisible) body area: endUpdate never brings the window underneath to front, and pointingOver (widget.go:62) rejects every widget of the lower window because the hovering root is the collapsed one.

update() already clipped collapsed windows to the title bar for InputCapturingStateHover (context.go:117), but it used BodyBounds.Min.Y, which is only refreshed while the window is expanded, so it goes stale once a collapsed window is dragged.

Fix

  • Add rootContainerHitBounds: for a collapsed window, the hit area is Bounds clipped to Bounds.Min.Y + style.titleHeight (the title bar drawn in doWindow). Only windows with a title bar can be collapsed, so this is always the visible area.
  • hoveringRootContainer delegates to a new rootContainerAt(p) that uses it; the hover check in update() uses the same helper, so both paths agree.

Invariant: a point is attributed to a root container only if it lies inside the part of that container that is drawn. Expanded windows and non-collapsible windows behave exactly as before. No public API change; cost stays O(number of root containers) per frame with no allocations.

Tests

TestCollapsedWindowDoesNotCoverWindowsBelow (uses the issue's layout) checks, through a test-only export of rootContainerAt:

  • expanded: title bar, body over the lower window, body only, outside
  • collapsed: title bar, last title-bar row (y=23), first row below it (y=24), former body over the lower window (now the lower window), former body only (nothing)
  • collapsed then dragged: old title bar position, new title bar position, lower window
  • expanded again

Before the fix, the test fails on the three "collapsed body / below title bar" cases (got the top window). After: go vet -vettool=./vettool ./... and go test -vet=all -race ./... pass on macOS/arm64. I did not add a cursor-driven test because the pointer is read from Ebitengine globals.

AI-assisted: I used Claude Code while investigating; I reviewed, ran and verified every change myself.

cc @hajimehoshi @venning

hoveringRootContainer hit-tested root containers against their full
Bounds even when collapsed, so a collapsed window kept winning clicks
over the windows underneath it and they could never be brought to front.

Use the title-bar-only area for collapsed windows in both
hoveringRootContainer and the InputCapturingStateHover check. The
latter used the last BodyBounds, which becomes stale when a collapsed
window is dragged; derive the title bar from Bounds and titleHeight
instead.

Closes ebitengine#55

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@hajimehoshi

Copy link
Copy Markdown
Member

Sorry but I've already fixed this (just a few minutes ago!)

@iamhuman-cheolheelee

Copy link
Copy Markdown
Author

No problem, thanks for the quick fix and for letting me know!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Collapsed window prevents windows underneath it from gaining focus

2 participants