mirror of
https://github.com/open-webui/open-webui.git
synced 2026-11-14 05:02:01 -06:00
[GH-ISSUE #18175] issue: Multi-lines input variables (text area) do not render properly in the conversation #34053
Reference in New Issue
Block a user
Originally created by @pierrelouisbescond on GitHub (Oct 9, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/18175
Check Existing Issues
Installation Method
Git Clone
Open WebUI Version
v0.6.32
Ollama Version (if applicable)
N/A
Operating System
Linux
Browser (if applicable)
Edge, Chrome
Confirmation
README.md.Expected Behavior
When using "textarea" in predefined prompts, I would expect that the text is rendered "as is", respecting original line breaks.
Actual Behavior
However, as shown below, line breaks are removed.
Steps to Reproduce
Create a predefined prompt with a "multi area" like {{insert_your_text_here | textarea}}
Logs & Screenshots
See below.
Additional Information
No response
@silentoplayz commented on GitHub (Oct 9, 2025):
I tested and was able to reproduce this issue with the following prompt of mine (picked this one to test with):
https://openwebui.com/p/iamg30/language-learning-practice-partner
Prompt:
When I paste the following into each fill-able field of the prompt with:
This is the result when I press
Save:@tjbck commented on GitHub (Oct 28, 2025):
Unable to reproduce with the latest dev, @silentoplayz confirmation wanted here!
@silentoplayz commented on GitHub (Oct 28, 2025):
Not able to reproduce anymore!
@pierrelouisbescond commented on GitHub (Nov 29, 2025):
Hi,
I'm using the v0.6.40 and the line breaks still do not render properly. Am I missing something?
@silentoplayz commented on GitHub (Nov 30, 2025):
Can you please share the prompt you're using to test this issue out with?
@pierrelouisbescond commented on GitHub (Nov 30, 2025):
Of course, here it is:
@silentoplayz commented on GitHub (Nov 30, 2025):
Looks fine to me. Perhaps this issue is browser specific?
@pierrelouisbescond commented on GitHub (Nov 30, 2025):
Probably... I've checked with different browsers (Edge 142.0.3595.94, Chrome 142.0.7444.176, Opera 124.0.5705.65) and prompts, none of them render the break lines properly. I'm on Windows 11 btw...
@mysteryx93 commented on GitHub (Feb 10, 2026):
Why is this issue closed? Copy-pasting with line breaks still isn't working in v0.7.2
I copy this from plain text editor into the chat box
It pastes with a single line break instead of 2.
BUT interestingly, if I copy/paste from that textarea back into text editor, I can see that the line break is still present! Which means the correct line breaks are in the textarea, it looks like a display bug.
Note: I'm using Linux
@Classic298 commented on GitHub (Feb 10, 2026):
@mysteryx93 because as you can see from above conversation, multiple attempts of reproduction were unsuccessful
@pierrelouisbescond commented on GitHub (Feb 10, 2026):
@mysteryx93 Same here. The line breaks are still not rendered properly on our side. Could you pls describe your config to see if there's anything in common between our configs?
@mysteryx93 commented on GitHub (Feb 10, 2026):
Well, it's deployed via Docker container image on a Ubuntu server. Not much special configuration at all. Client-side, I'm using Linux, trying with the 2 most popular browser: Firedragon and Vivaldi
Line breaks are weird. First, I now understand that the chat box is markdown format which complicates things; line breaks are different in markdown than in standard text, and that's kind of a hybrid textarea.
I open a new chat, enter
select, copy, paste into text editor, I get
I write in text editor
select, copy, paste into text area of OpenWebUI, I get
but I select it back, copy, paste into text editor again, and I get
...
ALSO -- line height in textarea is considerably higher than necessary; just a slight annoyance for multi-line prompts
@pierrelouisbescond commented on GitHub (Feb 12, 2026):
Azure Container Apps hosting on our side (= managed Kubernetes with Debian Linux 12)
Client side: Windows 11 + Edge or Chrome
I was wondering if the "send" method (Enter or Ctrl+Enter) might be the cause (because you either need to type "Shift+Enter" or "Enter" to get a break line)... but it does not seem so...