[Bug]: Can't change Keybindings

[Ar-Kareem]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

1. Open app.t3.codes
2. go to keybindings
3. try to change anything (either change the hotkey for a keybinding or the 'when' condition)
4. click save... nothing happens and "save" button is still there

Expected behavior

Keybindings to update or some warning/error to appear telling me what's happening

Actual behavior

No feedback whatsoever. The blue "Save" button still exists despite clicking it infinite times.

Attached is me trying to change multiple keybindings (first is hotkey, second is the condition)

This image is the network call after clicking the "Save" button 25 times. No network call is happening:

This image is the console after clearing it then clicking the "Save" button another 25 times. No console log is appearing (except a cookie error message that is related to the timing of me clicking the save button)

Impact

Minor bug or occasional failure

Version or commit

v0.0.40 web

Environment

Firefox 154.0 (64-bit)

Logs or stack traces

None. Except for the probably irrelevant console log:

Cookie “_cfuvid” has been rejected for invalid domain. touch
Cookie “_cfuvid” has been rejected for invalid domain. touch

Screenshots, recordings, or supporting files

No response

Workaround

None. I have to deal with default keybindings despite conflicting with important terminal keyboard shortcuts.

[juliusmarminge]

Triage

Confirmed as a real settings-write bug, not a duplicate of #11108 (that one is about sibling drafts resetting after a successful save).

What we think is going on

Settings → Keybindings keeps edits in local React draft state. Save is supposed to persist via WebSocket RPC server.upsertKeybinding to each connected environment in the current settings scope (KeybindingsSettings.tsx), then the server writes keybindings.json.

Two things line up with “I click Save forever and nothing happens”:

1. Silent no-op when there is no connected write target. saveKeybinding does if (!primaryEnvironment) return with no toast. primaryEnvironment here is the first connected environment in scope, not merely “a machine I can see.” If that list is empty, the handler exits, no RPC is sent, and the dirty Save button stays. The page still renders built-in defaults (DEFAULT_RESOLVED_KEYBINDINGS), so it looks fully editable.

   Other server settings already refuse this case (planScopedSettingsPatch / inert “Reconnect…”). Keybinding rows do not. The settings shell only blocks a disconnected environment scope; All / project / checkout still show the editor.

   On app.t3.codes this is especially easy to hit: the hosted app has no PrimaryConnectionTarget (every device is a remote pair). That is the same class of “reads look like defaults, writes vanish” as fix(web): point settings panels at a connected device #5692 / feat(web): settings only show up where they can actually be saved #5832.

2. No HTTP request is expected even when Save works. The write is a frame on the existing WebSocket, not fetch/XHR. An empty Network log (Fetch/XHR) does not prove the click never ran. What does prove the write did not apply is the Save button remaining dirty and the lack of an error toast.

The _cfuvid cookie messages are unrelated.

Surfaces

• Web + desktop share this editor. Mobile has no keybindings settings page.
• Entry point: Settings → Keybindings (and the Open keybindings.json control).

Workaround

Edit the environment’s keybindings.json directly (~/.t3/userdata/keybindings.json by default; see the Keybindings user doc). That path still works if the UI save is a no-op.

Suggested fix

In KeybindingsSettings, never silent-return on Save/Remove. If connectedEnvironments.length === 0, disable Save and show the same reconnect / hosted-app copy other server settings use. After that, re-check Firefox on app.t3.codes while a remote environment is actually connected (WS frames, not HTTP). If Save still no-ops in that state, next place to look is the capture-input onBlur re-render vs the Base UI Save button eating the click.

Related

• [Bug]: Saving a keybinding discards other unsaved keybinding edits #11108 / fix(web): preserve unsaved keybinding edits when saving another binding #11109 — different bug (unsaved sibling rows reset when another row saves)
• fix(web): point settings panels at a connected device #5692 / feat(web): settings only show up where they can actually be saved #5832 — hosted settings writes dropped with no feedback
• feat(web): keybinding settings as settings rows #8532 — current keybindings settings UI