[GH-ISSUE #23526] bug: balanced $$...$$ LaTeX display math is parsed unreliably and stray $$ can disrupt message rendering #20004

New Issue

GiteaMirror · 2026-04-20T02:35:07-05:00

GiteaMirror commented

2026-04-20 02:35:07 -05:00

Originally created by @asf0 on GitHub (Apr 9, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/23526

Check Existing Issues

I have searched for any existing and/or related issues.
I have searched for any existing and/or related discussions.
I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!).
I am using the latest version of Open WebUI.

Installation Method

Git Clone

Open WebUI Version

v0.8.12

Ollama Version (if applicable)

llamacpp 8703, models tested, Qwen3.5 35B, Gemma4 31B

Operating System

Ubuntu 25.10/Win11/Macos Sequoia

Browser (if applicable)

No response

Confirmation

I have read and followed all instructions in README.md.
I am using the latest version of both Open WebUI and Ollama.
I have included the browser console logs.
I have included the Docker container logs.
I have provided every relevant configuration, setting, and environment variable used in my setup.
I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation. My steps:
Start with the initial platform/version/OS and dependencies used,
Specify exact install/launch/configure commands,
List URLs visited, user input (incl. example values/emails/passwords if needed),
Describe all options and toggles enabled or changed,
Include any files or environmental changes,
Identify the expected and actual result at each stage,
Ensure any reasonably skilled user can follow and hit the same issue.

Expected Behavior

Balanced ... display math should always render correctly in chat messages.
Multiline ... display math should render correctly.
Unmatched or stray $$ should remain plain text and must not disrupt message rendering.
Normal prose containing dollar signs should remain unchanged.
Fenced ```math blocks should continue working as they do now.

Actual Behavior

Balanced ... display math is parsed unreliably and may fail to render.
Multiline display math may break depending on how the markdown/math parser segments the content.
Stray or unmatched $$ can interfere with the message rendering pipeline instead of being treated as plain text.
The issue appears to come from the markdown/math tokenization layer before KaTeX rendering, not from KaTeX alone.

Steps to Reproduce

Paste the following prompt exactly as written into the chat input and submit it:

Solve these briefly and show your work using the math formatting you would normally use.

If a graph has |E| = 58, what is the sum of all vertex degrees?
Use the Handshaking Lemma to explain why \sum \deg(v) = 2|E|.
Compute 2 \times 58 and explain the result.
Suppose 5 vertices have degree 4, 6 vertices have degree 5, and 7 vertices have degree 6. Compute


(5 \times 4) + (6 \times 5) + (7 \times 6).

If the total degree sum must be 116, solve for d in

92 + 8d = 116.

Write the final conclusion in one sentence using inline math like d=3 and |E|=58.
Also restate this identity on its own line:
[
\sum_{v \in V} \deg(v) = 2|E|
]
Finally, include one more display equation in this exact style:

x^2 + y^2 = z^2

Wait for the model response and inspect the rendered message output.
5. Check the rendering of:

inline math such as |E| = 58 and d=3
single-line display math such as \sum \deg(v) = 2|E|
multiline display math blocks delimited with ...
the final standalone x^2 + y^2 = z^2

Logs & Screenshots

Without fix applied.

With fix applied.

Additional Information

The issue appears to be in the frontend markdown/math parsing pipeline rather than in KaTeX itself. Open WebUI uses a custom markdown tokenizer for math before content reaches the KaTeX renderer, and balanced "$...$" segments are not being
handled robustly in all cases, especially with multiline display math or delimiter-adjacent text. Unmatched or malformed delimiters can also propagate through the renderer path instead of being left as plain text, which suggests the tokenizer
is passing unstable math segments downstream rather than normalizing or rejecting them safely before KaTeX rendering.

Originally created by @asf0 on GitHub (Apr 9, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/23526 ### Check Existing Issues - [x] I have searched for any existing and/or related issues. - [x] I have searched for any existing and/or related discussions. - [x] I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!). - [x] I am using the latest version of Open WebUI. ### Installation Method Git Clone ### Open WebUI Version v0.8.12 ### Ollama Version (if applicable) llamacpp 8703, models tested, Qwen3.5 35B, Gemma4 31B ### Operating System Ubuntu 25.10/Win11/Macos Sequoia ### Browser (if applicable) _No response_ ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [x] I am using the latest version of **both** Open WebUI and Ollama. - [x] I have included the browser console logs. - [x] I have included the Docker container logs. - [x] I have **provided every relevant configuration, setting, and environment variable used in my setup.** - [x] I have clearly **listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup** (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc). - [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation**. My steps: - Start with the initial platform/version/OS and dependencies used, - Specify exact install/launch/configure commands, - List URLs visited, user input (incl. example values/emails/passwords if needed), - Describe all options and toggles enabled or changed, - Include any files or environmental changes, - Identify the expected and actual result at each stage, - Ensure any reasonably skilled user can follow and hit the same issue. ### Expected Behavior - Balanced $$...$$ display math should always render correctly in chat messages. - Multiline $$ ... $$ display math should render correctly. - Unmatched or stray $$ should remain plain text and must not disrupt message rendering. - Normal prose containing dollar signs should remain unchanged. - Fenced ```math blocks should continue working as they do now. ### Actual Behavior - Balanced $$...$$ display math is parsed unreliably and may fail to render. - Multiline display math may break depending on how the markdown/math parser segments the content. - Stray or unmatched $$ can interfere with the message rendering pipeline instead of being treated as plain text. - The issue appears to come from the markdown/math tokenization layer before KaTeX rendering, not from KaTeX alone. ### Steps to Reproduce Paste the following prompt exactly as written into the chat input and submit it: Solve these briefly and show your work using the math formatting you would normally use. 1. If a graph has $|E| = 58$, what is the sum of all vertex degrees? 2. Use the Handshaking Lemma to explain why $$\sum \deg(v) = 2|E|$$. 3. Compute $$2 \times 58$$ and explain the result. 4. Suppose 5 vertices have degree 4, 6 vertices have degree 5, and 7 vertices have degree 6. Compute $$ (5 \times 4) + (6 \times 5) + (7 \times 6). $$ 5. If the total degree sum must be 116, solve for $d$ in $$92 + 8d = 116.$$ 6. Write the final conclusion in one sentence using inline math like $d=3$ and $|E|=58$. 7. Also restate this identity on its own line: \[ \sum_{v \in V} \deg(v) = 2|E| \] 8. Finally, include one more display equation in this exact style: $$x^2 + y^2 = z^2$$ Wait for the model response and inspect the rendered message output. 5. Check the rendering of: - inline math such as $|E| = 58$ and $d=3$ - single-line display math such as $$\sum \deg(v) = 2|E|$$ - multiline display math blocks delimited with $$ ... $$ - the final standalone $$x^2 + y^2 = z^2$$ ### Logs & Screenshots Without fix applied. <img width="1230" height="1226" alt="Image" src="https://github.com/user-attachments/assets/3b6b34a9-9bf0-4bb8-a9ea-a51ef3c63aad" /> <img width="933" height="599" alt="Image" src="https://github.com/user-attachments/assets/e711286d-1573-42dd-864f-df2114afd53a" /> With fix applied. <img width="1235" height="1160" alt="Image" src="https://github.com/user-attachments/assets/0d3a5009-b2a7-4628-bd09-15253e5b40d4" /> <img width="873" height="507" alt="Image" src="https://github.com/user-attachments/assets/65aac890-65dc-4b84-8005-4f0bc9a8dad6" /> ### Additional Information The issue appears to be in the frontend markdown/math parsing pipeline rather than in KaTeX itself. Open WebUI uses a custom markdown tokenizer for math before content reaches the KaTeX renderer, and balanced "$$...$$" segments are not being handled robustly in all cases, especially with multiline display math or delimiter-adjacent text. Unmatched or malformed delimiters can also propagate through the renderer path instead of being left as plain text, which suggests the tokenizer is passing unstable math segments downstream rather than normalizing or rejecting them safely before KaTeX rendering.

GiteaMirror added the bug label 2026-04-20 02:35:07 -05:00

GiteaMirror closed this issue

2026-04-20 02:35:08 -05:00

GiteaMirror commented

2026-04-20 02:35:09 -05:00

@tjbck commented on GitHub (Apr 12, 2026):

Addressed in dev.

@tjbck commented on GitHub (Apr 12, 2026): Addressed in dev.

GiteaMirror commented

2026-04-20 02:35:10 -05:00

@asf0 commented on GitHub (Apr 12, 2026):

Glad to see this addressed. This matches the tokenizer approach I proposed in my PR (#23528).

@asf0 commented on GitHub (Apr 12, 2026): Glad to see this addressed. This matches the tokenizer approach I proposed in my PR (#23528).

GiteaMirror referenced this issue

2026-04-20 05:56:03 -05:00

[PR #20010] [CLOSED] perf: optimize /api/models endpoint performance using batched loading #25427

GiteaMirror referenced this issue

2026-04-25 13:22:59 -05:00

[PR #20010] [CLOSED] perf: optimize /api/models endpoint performance using batched loading #41057

GiteaMirror referenced this issue

2026-04-30 00:24:16 -05:00

[PR #20010] [CLOSED] perf: optimize /api/models endpoint performance using batched loading #48475

Sign in to join this conversation.