Repository navigation
Synthetic mouse input reached InputEvent.MouseButton.Pre all along. What was missing was any way to tell that a gameplay mod had deliberately taken a button from input that never arrived, and named KeyMapping taps published no input event at all.
Input event reporting
Every key, raw-key and world-mouse response now carries mod_input_event, listing each event the dispatch published and whether a mod cancelled it. /control/status gains mouse (grab and button state) and mod_input_events: running counts plus the last observed InputEvent.MouseButton.Pre, InputEvent.Key, InputEvent.MouseScrollingEvent and InputEvent.InteractionKeyMappingTriggered.
event_fired: false is not by itself proof that input was lost. Minecraft returns before publishing a key event when a screen consumes the key, exactly as it does for a physical keyboard.
Named mappings produce real input events
POST /control/key borrowed the mapping onto a spare keyboard key and called KeyMapping.click(). That updates isDown() and consumeClick(), so a mod that polls its mapping each tick responded, but it publishes no InputEvent.Key or InputEvent.MouseButton at all, so a mod that reads its controls from those events never saw the input. A mapping is now driven through the handler its bound key would use: MouseHandler.onPress for a mouse-bound mapping and KeyboardHandler.keyPress for a keyboard-bound one.
Passing "exact": true keeps the previous targeting, where the mapping is borrowed onto an unused keyboard key so only that mapping reacts; it now fires a real key event while doing so, and an unbound mapping always takes this route. A borrowed key cannot be held, and a mouse-bound mapping is refused while a screen is open, because the screen route would click whatever the pointer sits on instead of activating the mapping.
exact defaults to false, so a named tap behaves like the device the player would actually use, including for other mappings that share the same key.
Mouse grab in an isolated session
MouseHandler.grabMouse() is gated on Minecraft.isWindowActive(), and an isolated client never takes operating system focus. In practice the flag stays at its startup value of true, so the grab has been working, but it would be lost for good if that window ever gained and then lost focus, and Minecraft refuses to continue an attack or to turn the player while the mouse is ungrabbed. grabMouse now ignores the focus gate in an isolated session. The redirect is scoped to that one method, and the native cursor is still never captured.
MCP adapter
minecraft_client_input accepts an optional boolean exact for kind: "key".
Verification
Verified on a live isolated NeoForge 1.21.1 client running this exact JAR, against Ripples of the Past: a held synthetic left click broke oak planks in survival in 3.23 s; with a Stand summoned the same press was published and cancelled by the mod, and the Stand's punch played. The released 1.1.4 JAR breaks the same block in 3.22 s, which is the baseline showing the mouse path already reached gameplay. Details in docs/evidence/1.1.5-melee-input.json.
mineclient-bridge-neoforge-1.21.1-1.1.5.jar SHA-256: DC1C420A0C1CCE18026984AB49C58F4E7034409F5430FA2ED623AC16B48CFACE