AutopilotHUD: target-type toggle unclickable — hit-area overlaps 'Go to Position' command button #812

New Issue

2026-07-23T09:37:40Z

spikerj commented

2026-07-23 09:37:40 +00:00

Summary

In AutopilotHUD (space-game/hud/autopilot-hud.ts), the "Target Selection" type toggle (Custom Position ⇄ Spacecraft) is unclickable: its click hit-area overlaps the last command button ("Go to Position"), and because handleClick uses this.hitAreas.find(...) (first match wins) with command buttons registered first, a click on the toggle dispatches the goToPosition command instead of toggling the target type.

Evidence (hit-area rects at default position)

command/goToPosition: x[60,380] y[264,284]
targetType:           x[60,380] y[265,285]   <-- ~fully overlaps the button above, 1px offset

The two rects share x-range and overlap in y[265,284]. Any click in the target-type row lands on goToPosition first.

Root cause

The command-button hit areas use y = posY + (screenHeight - posY - by); the target-type/spacecraft/target-point hit areas use a different formula y = posY + (contentStartY - y) - titleBarHeight. The two formulas disagree, so the target-type rect is placed on top of the last command button instead of below it.

Impact

The target type can never be switched to Spacecraft via mouse.
Consequently the spacecraft selector and target-point selector (both gated on currentTargetType === "spacecraft") are also dead — their click handlers early-return in custom mode.
Clicking the toggle silently issues a "Go to Position" autopilot command — an unexpected side effect.

Fix direction

Compute the target-type / spacecraft-select / target-point hit areas with the same screen-space mapping the command buttons use (screenHeight - by), or derive all hit areas from the meshes' actual positions in one pass, so no two rects overlap.

Notes

Found via unit tests in the frontend coverage sweep (PR #551). Current (buggy) behavior is pinned by a characterization test in autopilot-hud.spec.ts referencing this issue.

### Summary In `AutopilotHUD` (`space-game/hud/autopilot-hud.ts`), the **"Target Selection" type toggle** (Custom Position ⇄ Spacecraft) is unclickable: its click hit-area overlaps the last command button ("Go to Position"), and because `handleClick` uses `this.hitAreas.find(...)` (first match wins) with command buttons registered first, a click on the toggle dispatches the `goToPosition` **command** instead of toggling the target type. ### Evidence (hit-area rects at default position) ``` command/goToPosition: x[60,380] y[264,284] targetType: x[60,380] y[265,285] <-- ~fully overlaps the button above, 1px offset ``` The two rects share x-range and overlap in y[265,284]. Any click in the target-type row lands on `goToPosition` first. ### Root cause The command-button hit areas use `y = posY + (screenHeight - posY - by)`; the target-type/spacecraft/target-point hit areas use a different formula `y = posY + (contentStartY - y) - titleBarHeight`. The two formulas disagree, so the target-type rect is placed on top of the last command button instead of below it. ### Impact - The target type can never be switched to **Spacecraft** via mouse. - Consequently the **spacecraft selector** and **target-point selector** (both gated on `currentTargetType === "spacecraft"`) are also dead — their click handlers early-return in custom mode. - Clicking the toggle silently issues a "Go to Position" autopilot command — an unexpected side effect. ### Fix direction Compute the target-type / spacecraft-select / target-point hit areas with the same screen-space mapping the command buttons use (`screenHeight - by`), or derive all hit areas from the meshes' actual positions in one pass, so no two rects overlap. ### Notes Found via unit tests in the frontend coverage sweep (PR #551). Current (buggy) behavior is pinned by a characterization test in `autopilot-hud.spec.ts` referencing this issue.

spikerj commented

2026-07-29 16:05:13 +00:00

Re-verified against origin/master — NOT DONE. The bug is pinned as expected behaviour, not fixed.

projects/spikersoft/src/app/_components/_games/space-game/hud/autopilot-hud.spec.ts:86-97 carries a characterization block that says so explicitly:

// CHARACTERIZATION — spikersoft-issues#812 … These tests pin the CURRENT buggy behaviour; flip them when #812 is fixed.

with it("BUG #812: clicking the target-type toggle fires the goToPosition command instead of toggling") at :90 and it("BUG #812: spacecraft + target-point selectors stay dead …") at :97.

git log origin/master -- '*autopilot-hud*' shows the newest commit is 312568c9 — the commit that added those pinning tests. No subsequent commit touched autopilot-hud.ts.

Flagging this as a pattern rather than a one-off, because it has now bitten this audit four times. #809 (CourseModule.number never assigned), #810 (Boss.selectBossType() throws), #811 (wasm-voxel AES has no round function) and this ticket all have test(coverage) commits that reference the bug number and pin the broken behaviour. Searching git log --grep="#N" finds a commit and it reads like a fix.

The tests themselves are good practice — they're honestly labelled and they'll fail loudly when someone fixes the code. The hazard is purely at the tracker level: a ticket audit that trusts git log --grep will close all four as done. I've noted it in each so the next sweep doesn't.

Remaining: fix the hit-area overlap in autopilot-hud.ts (the toggle's clickable region overlaps the "Go to Position" command button), then invert the two characterization tests so they assert the corrected behaviour.

Re-verified against `origin/master` — **NOT DONE. The bug is pinned as expected behaviour, not fixed.** `projects/spikersoft/src/app/_components/_games/space-game/hud/autopilot-hud.spec.ts:86-97` carries a characterization block that says so explicitly: > `// CHARACTERIZATION — spikersoft-issues#812 … These tests pin the CURRENT buggy behaviour; flip them when #812 is fixed.` with `it("BUG #812: clicking the target-type toggle fires the goToPosition command instead of toggling")` at `:90` and `it("BUG #812: spacecraft + target-point selectors stay dead …")` at `:97`. `git log origin/master -- '*autopilot-hud*'` shows the newest commit is `312568c9` — the commit that *added* those pinning tests. No subsequent commit touched `autopilot-hud.ts`. **Flagging this as a pattern rather than a one-off**, because it has now bitten this audit four times. #809 (`CourseModule.number` never assigned), #810 (`Boss.selectBossType()` throws), #811 (wasm-voxel AES has no round function) and this ticket all have `test(coverage)` commits that reference the bug number and **pin the broken behaviour**. Searching `git log --grep="#N"` finds a commit and it reads like a fix. The tests themselves are good practice — they're honestly labelled and they'll fail loudly when someone fixes the code. The hazard is purely at the tracker level: a ticket audit that trusts `git log --grep` will close all four as done. I've noted it in each so the next sweep doesn't. **Remaining:** fix the hit-area overlap in `autopilot-hud.ts` (the toggle's clickable region overlaps the "Go to Position" command button), then invert the two characterization tests so they assert the corrected behaviour.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: spikerj/spikersoft-issues#812