Misc. bug: SvelteKit WebUI submits the unfinished query on IME word confirmation (macOS Safari)

[watamario15]

Name and Version

$ ./build/bin/llama-server --version
ggml_cuda_init: GGML_CUDA_FORCE_MMQ: no
ggml_cuda_init: GGML_CUDA_FORCE_CUBLAS: no
ggml_cuda_init: found 1 CUDA devices:
Device 0: NVIDIA GeForce RTX 5070 Ti, compute capability 12.0, VMM: yes
version: 6533 (51f5a45)
built with cc (GCC) 15.2.1 20250808 (Red Hat 15.2.1-1) for x86_64-redhat-linux

Operating systems

Mac

Which llama.cpp modules do you know to be affected?

llama-server

Command line

./build/bin/llama-server -hf ggml-org/gpt-oss-120b-GGUF -c 0 --jinja -ncmoe 31 --host 0.0.0.0 --port 59000

Problem description & steps to reproduce

The server OS doesn't matter, this is purely a WebUI issue.

Access the WebUI from macOS Safari, type in the "Ask anything..." box in Japanese. It will submit halfway after pressing the "word confirm" Enter key despite I'm still not finished writing yet.

(You may need to use the keyCode property which becomes 229 while on IME, as regular isComposing doesn't work correctly on Safari. Or just have an option to disable the "Enter to Submit" shortcut.)

First Bad Commit

b6500

Relevant log output

[nihilfacit]

In my environment, I was able to fix this issue by tweaking the following two if statements:

• tools/server/webui/src/lib/components/app/chat/ChatForm/ChatForm.svelte (for chat input area)
  

  llama.cpp/tools/server/webui/src/lib/components/app/chat/ChatForm/ChatForm.svelte

  Lines 99 to 101 in ef4c5b8

  	async function handleKeydown(event: KeyboardEvent) {
  	if (event.key === 'Enter' && !event.shiftKey) {
  	event.preventDefault();

• tools/server/webui/src/lib/components/app/chat/ChatMessages/ChatMessage.svelte (for chat edit area)
  

  llama.cpp/tools/server/webui/src/lib/components/app/chat/ChatMessages/ChatMessage.svelte

  Lines 109 to 111 in ef4c5b8

  	function handleEditKeydown(event: KeyboardEvent) {
  	if (event.key === 'Enter' && !event.shiftKey) {
  	event.preventDefault();

I changed them to:

if (event.key === 'Enter' && !event.shiftKey && event.keyCode !== 229) {

After building the Web UI and then building llama.cpp, the change takes effect.
The Web UI build instructions are in the tools/server/webui/README.md.

KeyboardEvent.keyCode is deprecated, so this may not be the ideal long‑term fix, but it works for now if you’re encountering the same problem.
Bits‑UI also uses keyCode in its code:
https://github.com/huntabyte/bits-ui/blob/694c337ae9a9391da7cf3f9fef1ff732d974bb3c/packages/bits-ui/src/lib/bits/command/command.svelte.ts#L1079-L1087

I use llama.cpp every day via the Web UI. Thank you.

Test environment

• llama.cpp b6700
• macOS 15.7.1
• Safari 26.0.1
• Node.js v22.20.0
• macOS built‑in Japanese Input Method

[allozaur]

KeyboardEvent.keyCode is indeed deprecated, but fortunately we have isComposing property¹ that should address this issue just fine. I've pushed in #16673, lemme know if this solves the problem for you!

Footnotes

1. https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/isComposing ↩

[watamario15]

Still having the same issue. Safari is notorious for not supporting isComposing correctly.

• https://x.com/tomoemon/status/1818131419975307770
• https://zenn.dev/spacemarket/articles/149aa284ef7b08#問題
• https://ageo-soft.info/programming_languages/javascript/12588/
• (...and many more can be found)

I know KeyboardEvent.keyCode is deprecated, but not that Safari is going to remove its implementation, and from my web search, this is the only way to handle macOS IME correctly on Safari. If you are against for using this deprecated API, then I guess adding an option to disable the "Enter to Submit" shortcut is the way to go.

[watamario15]

In my environment, I was able to fix this issue by tweaking the following two if statements:

• tools/server/webui/src/lib/components/app/chat/ChatForm/ChatForm.svelte (for chat input area)

    [llama.cpp/tools/server/webui/src/lib/components/app/chat/ChatForm/ChatForm.svelte](https://github.com/ggml-org/llama.cpp/blob/ef4c5b87ea2556ff8ca99cca3abdf48bdbca22f2/tools/server/webui/src/lib/components/app/chat/ChatForm/ChatForm.svelte#L99-L101)
  
  
      Lines 99 to 101
    in
    [ef4c5b8](/ggml-org/llama.cpp/commit/ef4c5b87ea2556ff8ca99cca3abdf48bdbca22f2)
  
  
  
  
  
      
        
         	async function handleKeydown(event: KeyboardEvent) { 
      
  
      
        
         		if (event.key === 'Enter' && !event.shiftKey) { 
      
  
      
        
         			event.preventDefault();
  

• tools/server/webui/src/lib/components/app/chat/ChatMessages/ChatMessage.svelte (for chat edit area)

    [llama.cpp/tools/server/webui/src/lib/components/app/chat/ChatMessages/ChatMessage.svelte](https://github.com/ggml-org/llama.cpp/blob/ef4c5b87ea2556ff8ca99cca3abdf48bdbca22f2/tools/server/webui/src/lib/components/app/chat/ChatMessages/ChatMessage.svelte#L109-L111)
  
  
      Lines 109 to 111
    in
    [ef4c5b8](/ggml-org/llama.cpp/commit/ef4c5b87ea2556ff8ca99cca3abdf48bdbca22f2)
  
  
  
  
  
      
        
         	function handleEditKeydown(event: KeyboardEvent) { 
      
  
      
        
         		if (event.key === 'Enter' && !event.shiftKey) { 
      
  
      
        
         			event.preventDefault();
  

I changed them to:

if (event.key === 'Enter' && !event.shiftKey && event.keyCode !== 229) {
After building the Web UI and then building llama.cpp, the change takes effect. The Web UI build instructions are in the tools/server/webui/README.md.

KeyboardEvent.keyCode is deprecated, so this may not be the ideal long‑term fix, but it works for now if you’re encountering the same problem. Bits‑UI also uses keyCode in its code: https://github.com/huntabyte/bits-ui/blob/694c337ae9a9391da7cf3f9fef1ff732d974bb3c/packages/bits-ui/src/lib/bits/command/command.svelte.ts#L1079-L1087

I use llama.cpp every day via the Web UI. Thank you.

Test environment

• llama.cpp b6700
• macOS 15.7.1
• Safari 26.0.1
• Node.js v22.20.0
• macOS built‑in Japanese Input Method

I think checking the both isComposing and keyCode is better, considering the deprecation of keyCode, thus appending && !event.isComposing && event.keyCode !== 229 to these two places. This indeed fixed the issue for me.

[allozaur]

I think checking the both isComposing and keyCode is better, considering the deprecation of keyCode, thus appending && !event.isComposing && event.keyCode !== 229 to these two places. This indeed fixed the issue for me.

Yeah, I will just add the event.keyCode !== 229 and a comment about that. That will be much more straightforward.

[allozaur]

@watamario15 54fbd8a should solve the problem

[watamario15]

It's fixed, thanks!