SetNuiFocusKeepInput in depth: letting the game keep its input

#What the native actually changes

The declaration is one line: SetNuiFocusKeepInput(keepInput), a client-only CFX native that takes a boolean. Its partner IsNuiFocusKeepingInput() returns the current state. Neither has any effect until an NUI frame holds focus through SetNuiFocus, which is why the basics are covered first in NUI focus and cursor.

Normally, when your page has focus, FiveM routes the keyboard (and the mouse, if the cursor is on) to the browser and the game stops receiving them. With keep input switched on, input goes to both: the page still gets keydown and mouse events, and the game still sees the same keys as controls. That is the whole feature. Everything else in this article is about living with the consequences.

#A correct open and close pair

Keep the three calls together in one function so no code path can forget one of them. The page is told to show itself after focus is set, which avoids a frame where the UI is visible but cannot be clicked.

local isOpen = false

local function setPhone(state)
    if state == isOpen then return end
    isOpen = state

    SetNuiFocus(state, state)
    SetNuiFocusKeepInput(state)
    SendNUIMessage({ action = 'visible', value = state })

    if state then
        StartControlLoop()
    end
end

RegisterNuiCallback('close', function(_, cb)
    setPhone(false)
    cb({})
end)

AddEventHandler('onResourceStop', function(name)
    if name ~= GetCurrentResourceName() then return end
    SetNuiFocusKeepInput(false)
    SetNuiFocus(false, false)
end)

Resetting keep input on stop matters more than it looks. A resource restarted during development with keep input still on can leave the next UI that takes focus in a strange half state. Treat both flags as something you own and must hand back.

#The block-list approach and its gaps

The first thing players notice with keep input on is the camera: moving the mouse over your phone also swings the view, and clicking an app fires the weapon in their hand. The usual fix is a per-frame thread that disables the controls you do not want.

The problem with a block-list is that it is never complete. Every framework adds its own keybinds, and emotes, hands-up or the target eye can still fire through your UI. The list above is a good minimum; the allow-list below is the robust version.

#The allow-list approach (recommended)

Instead of guessing which controls to block, block all of them and re-enable the handful the player should keep. DisableAllControlActions(0) followed by EnableControlAction calls in the same frame gives you exact control.

local ON_FOOT = { 30, 31, 32, 33, 34, 35, 21, 22 }
local IN_VEHICLE = { 59, 63, 64, 71, 72, 76 }
local ALWAYS = { 249 }

function StartControlLoop()
    CreateThread(function()
        while isOpen do
            DisableAllControlActions(0)

            for i = 1, #ALWAYS do EnableControlAction(0, ALWAYS[i], true) end

            if IsPedInAnyVehicle(PlayerPedId(), false) then
                for i = 1, #IN_VEHICLE do EnableControlAction(0, IN_VEHICLE[i], true) end
            else
                for i = 1, #ON_FOOT do EnableControlAction(0, ON_FOOT[i], true) end
            end

            Wait(0)
        end
    end)
end

Leave the vehicle exit control (75, F) disabled so a mis-click does not throw the player out of a moving car. If you want sprint to stay disabled while a phone is up for roleplay reasons, remove 21 from the list; the point of an allow-list is that these decisions become explicit.

#Reading keys while they are disabled

A disabled control still registers presses; it just stops the game acting on them. That means your Lua loop can listen for Backspace or Escape and close the UI without the pause menu opening. Use the IsDisabledControl… family, because IsControlJustPressed returns false for disabled controls.

if IsDisabledControlJustPressed(0, 200) or IsDisabledControlJustPressed(0, 177) then
    setPhone(false)
end

Control 200 is the Escape pause alternate and 177 is the phone cancel control (Backspace, Escape or right mouse by default). Handling the close in Lua rather than in the page has a bonus: it also works when the page has lost keyboard focus to an input field, which is the next topic.

#Typing in a text field with keep input on

With keep input on, every letter a player types into a message box also reaches the game. W walks forward, T opens chat and a number key might swap weapons. An allow-list reduces the damage but movement keys are, by design, still enabled. The clean fix is to switch keep input off while any text field has focus and restore it afterwards.

const isTextField = (el) =>
  el && (el.tagName === 'INPUT' || el.tagName === 'TEXTAREA' || el.isContentEditable);

document.addEventListener('focusin', (e) => {
  if (isTextField(e.target)) fetchNui('keepInput', { value: false });
});

document.addEventListener('focusout', (e) => {
  if (isTextField(e.target)) fetchNui('keepInput', { value: true });
});

RegisterNuiCallback('keepInput', function(data, cb)
    if isOpen then
        SetNuiFocusKeepInput(data.value == true)
    end
    cb({})
end)

The isOpen guard stops a late focusout (fired as the page hides) from switching keep input back on after the UI has closed. focusin and focusout bubble, unlike focus and blur, so one listener on the document covers every field. The fetchNui helper is the one from NUI callbacks with fetch. More keyboard edge cases are collected in NUI text inputs and keyboard bugs.

#When two UIs compete for focus

Focus is per frame, but the way keep input interacts between frames is less predictable. There is an open report on the FiveM tracker where a first UI sets keep input to true and a second UI then sets it to false, yet input keeps flowing to the game. In practice, three habits avoid most of these problems:

1. Always set keep input explicitly when you take focus, even to false. Never rely on the default.
2. Always set it back to false when you release focus, before SetNuiFocus(false, false).
3. Check IsNuiFocused() before opening; if another UI already holds focus, close it through its own export or event instead of stacking a second focused UI on top.

Frameworks with a central UI manager solve this once: every resource asks the manager to open, and the manager owns the focus flags. If you maintain several of your own UIs, a tiny shared export (requestFocus(name, cursor, keepInput) and releaseFocus(name)) is worth the ten lines it takes.

#Debugging focus state

When a player reports a stuck camera or an unclosable menu, you need to know the state at that moment. A small command prints it:

RegisterCommand('focusdebug', function()
    print(('focused=%s keepInput=%s'):format(
        tostring(IsNuiFocused()),
        tostring(IsNuiFocusKeepingInput())
    ))
end, false)

Check the page side too: open the NUI devtools and confirm the keepInput callback requests actually go out when a field gains and loses focus.