fix(input): stop crash when pressing Ctrl/Tab with no default bind - #5376
fix(input): stop crash when pressing Ctrl/Tab with no default bind#5376soloturn wants to merge 2 commits into
Conversation
#5224: pressing RIGHT_CTRL (or LEFT_CTRL/TAB once something else already claims the key with a default bind) crashes with IllegalArgumentException: moduleName must not be null or empty, from ResourceUrn.<init> via NUIManagerInternal.bindEvent(). ## Root cause SortOrderSystem.postBegin() creates fallback BindableButtonImpl instances for RIGHT_CTRL, LEFT_CTRL and TAB whenever BindsManager.getKeyBinds() doesn't already have an entry for that physical key - which is the common case, since only LEFT_CTRL has a @DefaultBinding (CrouchButton). Each fallback used the single-arg SimpleUri(String) constructor: new SimpleUri("ctrlMod") new SimpleUri("changeFocus") That constructor only sets moduleName/objectName when the string contains a ":" separator; without one it silently returns an invalid URI (both names empty) rather than failing fast. The bind system otherwise never notices - BindableButtonImpl just carries the id around - until NUIManagerInternal.bindEvent() calls event.getId().getModuleName()/getObjectName() straight into `new ResourceUrn(...)`, which does validate and throws. ## Fix Two parts, matching the pattern used elsewhere this session: 1. SortOrderSystem: build the ids with the proper SimpleUri(Name, String) constructor and TerasologyConstants.ENGINE_MODULE, the same convention the engine's own built-in binds use, so the ids are valid SimpleUris instead of just happening not to crash. 2. NUIManagerInternal.bindEvent(): added a defensive event.getId().isValid() guard that logs and returns instead of constructing the ResourceUrn, so any other future malformed bind id (module or third-party code, not just this one call site) degrades to a log line instead of taking the whole input pipeline down. ## Verification :engine:compileJava and :engine-tests:compileTestJava both clean. No existing test exercises SortOrderSystem or NUIManagerInternal.bindEvent directly - both need a live BindsManager/NUI event pipeline, not something unit-testable in isolation. Root-caused and fixed by tracing the exact SimpleUri construction and validation path named in the issue's own stack trace, matching soloturn's confirmation comment that this still reproduces on current develop. Fixes #5224 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
Included review availability: Your plan provides up to 8 included reviews per hour; 7 remain after this review. 📝 WalkthroughSummary by CodeRabbit
WalkthroughThe change scopes fallback key-binding identifiers to the engine module and rejects invalid bind IDs before NUI bind-event processing. ChangesBind Identifier Handling
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This change prevents malformed input bindings from crashing the input pipeline and safely ignores invalid identifiers. No actionable merge-blocking risk remains after normal checks and review. Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
LineLength: three keys.put(...) calls building CTRL/TAB BindableButtonImpl fallbacks exceeded the 150-char limit. Wrapped the constructor argument onto its own line; no behavior change. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Fixes #5224 - pressing RIGHT_CTRL (or LEFT_CTRL/TAB once something else already claims the key) crashes with
IllegalArgumentException: moduleName must not be null or empty.Root cause
SortOrderSystem.postBegin()creates fallbackBindableButtonImplinstances for RIGHT_CTRL, LEFT_CTRL and TAB wheneverBindsManager.getKeyBinds()doesn't already have an entry for that physical key - the common case, since only LEFT_CTRL has a@DefaultBinding(CrouchButton). Each fallback built its id with the single-arg constructor:SimpleUri(String)only populatesmoduleName/objectNamewhen the string contains a:separator; without one it silently returns an invalid URI (both names empty) instead of failing fast:The bind system doesn't notice -
BindableButtonImpljust carries the id around - untilNUIManagerInternal.bindEvent()callsevent.getId().getModuleName()/getObjectName()straight intonew ResourceUrn(...), which does validate and throws. Matches the stack trace in the issue exactly (bindEvent,BindableButtonImpl.updateBindState).Fix
SortOrderSystem- build the ids with the properSimpleUri(Name, String)constructor andTerasologyConstants.ENGINE_MODULE, the same convention the engine's own built-in binds use.NUIManagerInternal.bindEvent()- added a defensiveevent.getId().isValid()guard that logs and returns instead of constructing theResourceUrn, so any other malformed bind id (module code, not just this call site) degrades to a log line instead of taking down the input pipeline.Verification
:engine:compileJavaand:engine-tests:compileTestJavaboth clean. No existing test exercisesSortOrderSystemorNUIManagerInternal.bindEventdirectly - both need a liveBindsManager/NUI event pipeline, not something unit-testable in isolation.Root-caused and fixed by tracing the exact
SimpleUriconstruction/validation path named in the issue's own stack trace, matching soloturn's comment confirming this still reproduces on current develop.