Jedi Select Components: overlapping dialog input
The ordinary mouse failure is a renderer hit-order defect, not a misplaced
replay click. The fix ranks distinct top-level window trees by their painted
stacking order before applying the existing embedded-dialog preference.
It changes only lib/renderer-input.js; no installer or app-specific behavior
is added. Original installation and game launch remain unverified.
Evidence and cause
Reviewed run 20261020-jedi-original-accept-launch, report commit
c0de2a2040954dc1ff58668f19e7b619fe442855, actual installer log, click receipt,
stop snapshot, and before/after PNGs. License Yes acceptance was observed.
The original installed payload was absent; only deisl1.isu was present.
The snapshot records:
| Window | Coordinates | Size | Relationship |
|---|---|---|---|
Setup 0x10001 |
0,0 | 640×480 | top-level |
Progress 0x1000f |
155,304 | 323×139 | child of Setup |
Components 0x1006b |
80,59 | 480×362 | owned popup, not child |
Progress coordinates are parent-client relative, not screen coordinates.
With Setup's client origin (3,23), its screen rectangle begins (158,327),
and its own client begins (161,350). The log's mouse lParam 0x002d00fe
is precisely (415−161,395−350) = (254,45). Components' client begins
(83,82). The logged Next control 0x10077, ID 1, has client rectangle
(295,301,75,23): its screen rectangle is (378,383,75,23). Click (415,395)
is inside it, at button-local (37,12). No coordinate correction is needed.
Before the fix handleMouseDown sorted same-instance overlapping dialogs by
area. Progress has area 44,897, Components 173,760. The smaller hidden-behind
surface won despite Components being visibly on top. The actual-source
regression chooses 0x1000f on baseline, matching the run. Subsequent
activation of that surface explains the caption change visible after the
click. The captured WM_CHAR 13 went to focus 0x10001; it was not an Enter
keydown/keyup sequence. This task does not establish an independent keyboard
or modal-manager defect, and changes neither.
The fix uses existing _findTopWindow / production wnd_top_level and
_compareTopLevelZ. wnd_top_level follows WS_CHILD parentage only, so the
owned Components popup remains its own top-level surface. Within the same
surface, embedded wizard-page behavior is preserved. Existing desktop and
cross-process ordering remain in place.
Bounded regression
Run from the checkout:
node test/test-jedi-components-input.js
node test/test-renderer-dialog-modal-input.js
node test/test-renderer-dialog-button-queue.js
All pass. The dedicated test calls actual handleMouseDown/handleMouseUp
at (415,395). It compiles unchanged production wnd_top_level,
dialog_route_mouse_screen, dialog_route_mouse, and ctrl_style_disabled
with the canonical WATX compiler. The 1,119-byte module SHA-256 is
f24f3533441957d52c465350428aa0654d47e8d1e35525d1a4809c4c802c1ddc.
The router delivers DOWN and UP to 0x10077 with correct child coordinates.
Window metadata, chrome layout, repaint/activation side effects and the final
wndproc delivery boundary are explicit adapters. No button activation,
BN_CLICKED processing, guest continuation, full VM or browser is claimed.
No WM_COMMAND is injected.
Controls cover hidden progress, larger progress, an embedded wizard page,
and a different popup genuinely above Components. All pass. These commands
must fail at the first real DOWN target assertion (0x1000f vs 0x1006b):
node test/test-jedi-components-input.js --baseline
node test/test-jedi-components-input.js --mutate-owner-as-parent
node test/test-jedi-components-input.js --mutate-reverse-z
All three fail as intended, not at compilation or fixture setup. The first loads the pre-fix production renderer, the second wrongly climbs popup ownership in the compiled ancestry function, and the third reverses surface stacking order. The test is automatically in the default unit tier.
Preservation and limits
Evidence: scratch/runs/20261020-jedi-components-input-fix/, including actual
input/log/snapshot and PNG copies, source identities, test logs, preflight,
checks and publication receipt. Production routing/compiler inputs are
identical between actual tested source 14792a36 and reconciled main
aaf8599291b278b5cf1b9e53c654b5bb8cd5dfe6. Fresh main
71a60db4004e5df74cfa232f7a59edc109ffc660 adds only the independent MadBomber
registry/report/test changes; no routing overlap.
Work used an isolated exact sparse task checkout. An initial setup error ran read-tree before installing sparse patterns and briefly materialized 244 MiB, exceeding the 12 MiB task cap. It was immediately pruned to the exact admitted paths; the disk floor plus reserves was never breached. Git also automatically added this task's upstream stanza; only that stanza was removed, restoring the shared config's exact original hash. Shared HEAD/index were unchanged. These deviations are recorded rather than represented as a clean preflight.
No runtime, browser, heavy build, main merge, workers, registry edits, synthetic payloads or installer bypass occurred. A later coordinator-assigned ordinary installer replay must establish advancement and investigate missing payloads. This source fix is not an installed-game or playable claim.