Summary
On macOS, after a game starts in a UI-only input mode (a main menu) and later switches to game-only input, no raw mouse movement reaches the game. Mouse look is dead. Keyboard and mouse buttons work, the viewport holds mouse capture, and the cursor is hidden. It happens when the mouse is moving as the game window activates, which is nearly every real launch. A launch straight into a game-only level is not affected. Setting Slate.MacUseNewMouseControllerMovement=0 in [SystemSettings] fixes it.
What Type of Bug are you experiencing?
Platform Other
Steps to Reproduce
- In a project, make the default map’s player controller add a UMG widget and call SetInputMode(FInputModeUIOnly()) in BeginPlay.
- On a button press, call SetInputMode(FInputModeGameOnly()) and OpenLevel to a level with a mouse-look pawn.
- Launch the game on macOS (-game -windowed is enough). Move the physical mouse while the window comes up and activates.
- Click the button, then move the mouse in the gameplay level.
Expected Result
The camera turns with the mouse, as it does when the game launches straight into the gameplay level.
Observed Result
The camera never turns. No MouseX/MouseY input reaches the viewport, and the cursor’s reported position never changes between clicks. With -LogCmds=“LogAppleController Verbose”, “HighPrecisionMouseMode Enabled” is logged at step 4 with no “Handling physical mouse connection” lines after it, so the GCMouse handlers are not rebound. In a working run, a batch of those lines follows immediately.
Affects Versions
5.8
Platform(s)
Mac
Additional Notes
Reading MacApplication.cpp and AppleMouseController.cpp in 5.8.3, the sequence is:
- FAppleMouseController binds GCMouse mouseMovedHandler at startup, and bEnabled defaults to true (AppleMouseController.h:131), so movement accumulates even outside high-precision mode.
- When the window or app activates, FMacApplication::ReassociateMouseInput (MacApplication.cpp:526) calls SuspendMovementHandler, which nils the handlers, and sets bMouseInputNeedsReassociation = true.
- A delta already accumulated in CurrentMovementState from a mouse moving at that moment is still dispatched on the next SendControllerEvents (DispatchMovementUpdates, AppleMouseController.cpp:156). HandleMouseControllerMovement (MacApplication.cpp:1058) then clears bMouseInputNeedsReassociation because the delta is nonzero.
- The handlers are now suspended and the flag is false. ProcessMouseMovedEvent (MacApplication.cpp:1093) skips the NSEvent path in high-precision mode, and SetHighPrecisionMouseMode(true) (MacApplication.cpp:509) skips RebindMouseHandlers. No movement arrives from either source.
A launch straight into game-only input avoids it because the viewport calls SetHighPrecisionMouseMode(true) at window activation, while the flag is still true, so the handlers are rebound before the stale delta lands. A UI-only front end defers high-precision mode until later, so the stale delta always wins.
Possible fixes: discard CurrentMovementState (and PendingDeltaXY) in SuspendMovementHandler, or track whether the handlers are suspended explicitly instead of inferring it from the first nonzero delta.
Workaround: [SystemSettings] Slate.MacUseNewMouseControllerMovement=0 in DefaultEngine.ini. Movement goes back to AppKit and mouse look works after the menu.
A synthetic mouse (CGEventPost) cannot reproduce this, because GCMouse ignores posted events. It needs a physical mouse.