mirror of
https://github.com/open-webui/open-webui.git
synced 2026-05-06 10:58:17 -05:00
[GH-ISSUE #16337] issue: Typing ``` 3 backticks followed by <shift-enter> removes backticks if "Enter Key Behavior" is "Enter to Send" #56532
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @scottrbaxter on GitHub (Aug 6, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/16337
Check Existing Issues
Installation Method
Git Clone
Open WebUI Version
V0.6.18
Ollama Version (if applicable)
N/A
Operating System
macOS Sequoia
Browser (if applicable)
Brave Browser (1.80.125), Microsoft Edge, Safari WebApp
Confirmation
README.md.Expected Behavior
start with the cursor at any empty line in the text input dialog box
Actual Behavior
backticks are unintentionally removed and cursor appears at beginning of line
Steps to Reproduce
Begin with a new empty prompt
Logs & Screenshots
pressed "shift-enter" to add a newline and the 3 backticks on the 2nd line vanish
Additional Information
this bug began recently, within the last 1-2 months. 100% reproducible and occurs on multiple macs, and different browsers. I've launched 3 different open-webui deployments with unique configurations, and this occurs on all of them.
the only way to keep 3 backticks from being removed is if they are not the first characters on the line. alternatively, pasting in a block of code and then adding 3 backticks below this text, then scrolling back up to the beginning of this input text, adding a newline and finally adding 3 backticks. this band-aid works, but is very unintuitive and not user friendly. afterwords, i must move the cursor with arrow keys or add more characters before i can use shift-enter to add a newline, else they will be unintentionally removed again. (fwiw, 1, 2, 4, 5, or 6, etc. backticks will persist, but 3 will disappear).
the only solution i've found is to change
Enter Key BehaviortoCtrl+Enter to Send, but this wasn't required until very recently and i would prefer to not have to change this behaviour just for ease of use with code blocks.this seems to only affect lines that start with 3 backticks, directly followed by pressing shift-enter to add a newline. any other characters before or after will result in "shift-enter" producing a newline below the current text, as anticipated.
@jay3ss commented on GitHub (Aug 7, 2025):
This happens to me too. The way I work around it is to type three backticks then hit the space key and it'll create the code block and put your cursor in it. If you want the syntax highlighting it works with that too, just have to type three backticks and then the language then hit space and you'll get the language's syntax highlighting in the code block
@humblemodulo commented on GitHub (Aug 7, 2025):
Same, very frustrating. Been happening for a while.
@Rain6435 commented on GitHub (Aug 7, 2025):
This has been fixed as per my PR.
@scottrbaxter commented on GitHub (Aug 11, 2025):
@Rain6435 I just updated to
v0.6.21and this issue persists. It appears as though your solution was implemented already.Could you please explain how you tested and confirmed this solution? This issue should not be closed yet, but i cannot re-open it even though i created it.
@humblemodulo commented on GitHub (Aug 11, 2025):
@scottrbaxter It persisted for me as well until I cleared browser cache. Now it enters a sort of "markdown mode" (rather than simply leaving plain backticks) when you
cmd/ctrl + enter.@Rain6435 commented on GitHub (Aug 11, 2025):
@scottrbaxter please understand that m'y solution wasn't integrated by @tjbck . Please address him regarding this matter.
In my opinion, the solution of @tjbck is pretty rudimentary and exclusively covers the issue but not all edge cases. If you would like to checkout to my branch and tell me if you still see the issue, I would be interested in seeing what you get because I thoroughly tested it.
@scottrbaxter commented on GitHub (Aug 11, 2025):
@humblemodulo I see, tested with another browser and i do also notice the "markdown mode" code block bubble... however, that only happens with three backticks alone on a line. now i can't ever include a language specific code block, e.g. "three backticks" followed by "python" on the line... if i add any character other than a 4th backtick, the line gets cleared, which is actually the opposite of the original issue i submitted, however, still causes an issue directly related to markdown syntax highlighting.
@Rain6435 my mistake, thanks for clarity.
@tjbck this change modifies but does not fix the original issue. Is this auto "markdown mode" code block bubble supposed to forcibly pop up in this use case? If so, that will potentially cause pasting issues, which will either require manual edits or incorrectly formatted markdown preview upon submission. Perhaps I'm misunderstanding what "manually" means in this statement.
Entering this "markdown mode" thing is not manual, since it's automatically formatting my text input for a visual interpretation. Is there a way that users can toggle the ui visual manipulation off, so we can explicitly guarantee clear formatting when markdown is submitted? I often struggle with output request/prompt that gets returned is visually not formatted as expected (would absolutely love a markdown "preview" button similar to github comments 🙃). my fix has been to stop the model from proceeding, edit the prompt, fix the incorrectly formatted text, and re-run. it's not obvious when this will happen and sadly, it's not easy to 100% reproduce, which is why i've not submitted a formal github issue for it, yet. If i don't do this, then the incorrectly formatted prompt remains in history this way, which is not ideal. It's also wasteful, and potentially costly, having to redo prompts over time. If users are able to disable the auto-visual changes before submitting the user prompt (but i'd still like to see the correctly formatted markdown on submission), this would be ideal for a general "manual" markdown creation... (similar to Slack, i suppose). tbh, it doesn't need to be limited to multi-line code blocks, but i'd be happy to see that if that's an easier solution.
Could this issue please be re-opened until there's a complete solution?
@scottrbaxter commented on GitHub (Aug 31, 2025):
It seems this is not going to get further attention unless a new issue is created. for anyone stumbling upon this issue and would like an alternative, there a user option under
Settings / UIto simply toggleRich Text Input for Chatoff, so that no rich text/markdown will not be generated until submitting the query. Where not a direct replacement, at least this issue doesn't have a chance to occur... might save a lot of retyping.