feat: move Enter Key Behavior into Settings > Keyboard as a configurable Send Message shortcut

[silentoplayz]

Summary

The key that sends a message is chosen under Settings > Interface, as a two-state button called Enter Key Behavior. Every other key-driven action lives under Settings > Keyboard, where it can be rebound. I propose moving the send key there as a Send Message shortcut, while keeping one thing exactly as it is today. The send key works whether or not keyboard shortcuts are enabled.

Problem / Motivation

Today there are two places that decide what my keys do in the chat input, and they do not know about each other.

Settings > Interface has a section called Input with a button labeled Enter Key Behavior. Clicking it toggles between "Enter to Send" and "Ctrl+Enter to Send". Those are the only two choices, and it is the only key-driven action in Open WebUI that is configured outside the Keyboard page. The two choices are not symmetrical either. With "Enter to Send", both Enter and Ctrl+Enter send the message. With "Ctrl+Enter to Send", only Ctrl+Enter does.

Settings > Keyboard lists every shortcut by category (Chat, Global, Input, Message, Voice). Several can be rebound by clicking the key and pressing a new combination. Any of them can be unassigned, and there is a Reset Defaults button. It also has a master toggle, Enable Keyboard Shortcuts, described as "When disabled, keyboard shortcuts will not trigger any actions."

The Input category on that page already holds Focus Chat Input, Accept Autocomplete, Prevent File Creation, Attach File From Knowledge, Add Custom Prompt, and Talk to Model. A person looking for "which key sends my message" reasonably looks there first, finds nothing, and has to know to go to Interface instead. Once they find the button, they get two choices where the Keyboard page would give them any combination.

Proposed Solution

Add a Send Message row to the Input category of Settings > Keyboard. It is configurable like Focus Chat Input, with a default of Enter. Choosing Ctrl+Enter, Cmd+Enter, or anything else works the same way as rebinding any other shortcut on that page. Shift+Enter keeps inserting a line break, as it does now. Ctrl+Enter also keeps sending no matter what the row is bound to, since it sends in both of today's modes and people have that in muscle memory. The row then decides only which other key sends as well, with Enter as the default.

The Enter Key Behavior button under Interface either goes away or stays as a shortcut to the same setting, so both pages agree. Anyone who already picked Ctrl+Enter keeps it.

One thing must carry over unchanged from today. Enter Key Behavior is not a shortcut, so turning off Enable Keyboard Shortcuts has never affected it. Enter or Ctrl+Enter sends the message either way. Moving the setting onto the Keyboard page must not change that. The master toggle exists so that key combinations do not trigger actions unexpectedly, and sending a message is what the input is for, so the Send Message row stays exempt from the toggle. It would be the only row on the page with that exemption, and the row can say so in its tooltip, the same way Prevent File Creation explains its own condition.

Touch devices are unchanged. On a phone, Enter already inserts a newline and the send button does the sending. That stays.

Alternatives Considered

• Leave it under Interface and add a third or fourth choice to the button. This keeps the split between two settings pages, and every added choice makes the button read more like the Keyboard page it is avoiding.
• Show the row on the Keyboard page but keep the real setting under Interface, with the row as a mirror. This fixes discoverability but keeps two sources of truth, and a mirrored row that cannot be rebound would be the only such row on the page.
• Gate the send key by the master toggle like everything else, and fall back to Enter when shortcuts are off. This is simpler to reason about, at a cost. Turning shortcuts off would silently change the send key for anyone who had chosen Ctrl+Enter, which does not happen today. That is the kind of surprise the toggle is meant to prevent.

Additional Context

• The original request for a setting on the send key was Enter key doesn't send message #1922, back when Enter had briefly stopped sending. The two-state button was the answer then, before the Keyboard page existed.
• Keyboard shortcuts to support voice first operation - and configurable shortcuts #9513 asked for configurable shortcuts in general, which the Keyboard page now provides. The send key is the one key-driven action that did not move with it.
• Under the hood, the two are separate per-user settings today. One is a yes/no value for Ctrl+Enter and the other is the keybinding map the Keyboard page edits. A Send Message shortcut would replace the boolean with an entry in that map, which is where the migration for existing Ctrl+Enter users would happen.