[GH-ISSUE #14998] issue: Banners need a max character limit; here's why #17435

New Issue

GiteaMirror · 2026-04-19T23:11:22-05:00

GiteaMirror commented

2026-04-19 23:11:22 -05:00

Originally created by @silentoplayz on GitHub (Jun 15, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/14998

Originally assigned to: @tjbck on GitHub.

Check Existing Issues

I have searched the existing issues and discussions.
I am using the latest version of Open WebUI.

Installation Method

Docker

Open WebUI Version

v0.6.14

Ollama Version (if applicable)

v0.9.0

Operating System

Edition: Windows 11 Pro | Version: 24H2 | OS Build: 26100.4351 | Windows Feature Experience Pack: 1000.26100.107.0

Browser (if applicable)

LibreWolf v135.0.1-1 (Firefox)

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

Banners should have a practical character limit (e.g., 512 characters) to prevent them from obscuring or completely blocking the New Chat page content, including the chat input box and prompt suggestions.

Actual Behavior

Banners currently have no enforced character limit, which allows a single banner containing a large amount of text to entirely fill the New Chat page, pushing the chat input box and prompt suggestions off-screen and preventing user interaction.

Steps to Reproduce

Access the Open WebUI Admin Panel.
Navigate to the Interface tab.
Scroll down to the UI section and click "Add New Banner".
Select a banner type and then paste a large body of text (e.g., 10,000+ characters) into the banner content field.
Optionally, toggle off the Dismissable option for the banner to make the issue more persistent.
Save your changes.
Navigate to the New Chat page.
- Observe: The large banner completely occupies the screen, pushing the chat input box and Default Prompt Suggestions out of view, and preventing interaction.

Logs & Screenshots

See attached screenshot:

Additional Information

This issue significantly impairs usability, as large banners can completely obscure essential UI elements like the chat input box and Default Prompt Suggestions on the New Chat page. Furthermore, scrolling is not enabled to access these off-screen elements, effectively preventing users from initiating new chats.

Originally created by @silentoplayz on GitHub (Jun 15, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/14998 Originally assigned to: @tjbck on GitHub. ### Check Existing Issues - [x] I have searched the existing issues and discussions. - [x] I am using the latest version of Open WebUI. ### Installation Method Docker ### Open WebUI Version v0.6.14 ### Ollama Version (if applicable) v0.9.0 ### Operating System Edition: Windows 11 Pro | Version: 24H2 | OS Build: 26100.4351 | Windows Feature Experience Pack: 1000.26100.107.0 ### Browser (if applicable) LibreWolf v135.0.1-1 (Firefox) ### 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 Banners should have a practical character limit (e.g., 512 characters) to prevent them from obscuring or completely blocking the `New Chat` page content, including the chat input box and prompt suggestions. ### Actual Behavior Banners currently have no enforced character limit, which allows a single banner containing a large amount of text to entirely fill the `New Chat` page, pushing the chat input box and prompt suggestions off-screen and preventing user interaction. ### Steps to Reproduce 1. Access the Open WebUI Admin Panel. 2. Navigate to the `Interface` tab. 3. Scroll down to the `UI` section and click "Add New Banner". 4. Select a banner type and then paste a large body of text (e.g., 10,000+ characters) into the banner content field. 5. Optionally, toggle off the `Dismissable` option for the banner to make the issue more persistent. 6. Save your changes. 7. Navigate to the `New Chat` page. * **Observe:** The large banner completely occupies the screen, pushing the chat input box and `Default Prompt Suggestions` out of view, and preventing interaction. ### Logs & Screenshots See attached screenshot: ![Image](https://github.com/user-attachments/assets/6c8e6622-0d9d-47b7-a579-9b9d8c692912) ### Additional Information This issue significantly impairs usability, as large banners can completely obscure essential UI elements like the chat input box and `Default Prompt Suggestions` on the `New Chat` page. Furthermore, scrolling is not enabled to access these off-screen elements, effectively preventing users from initiating new chats.

GiteaMirror added the bug label 2026-04-19 23:11:22 -05:00

GiteaMirror closed this issue

2026-04-19 23:11:23 -05:00

GiteaMirror commented

2026-04-19 23:11:24 -05:00

@tjbck commented on GitHub (Jun 16, 2025):

Should be addressed with afca606063900d0de46c1cb19ae8f58e7a8dfff0!

@tjbck commented on GitHub (Jun 16, 2025): Should be addressed with afca606063900d0de46c1cb19ae8f58e7a8dfff0!

GiteaMirror commented

2026-04-19 23:11:25 -05:00

@silentoplayz commented on GitHub (Jun 16, 2025):

Should be addressed with afca606!

This ironically is a justifiable fix. Let's just hope I don't find a way to break banners further. 😉

Wait a minute... what's this? 👀 😅

@silentoplayz commented on GitHub (Jun 16, 2025): > Should be addressed with [afca606](https://github.com/open-webui/open-webui/commit/afca606063900d0de46c1cb19ae8f58e7a8dfff0)! This ironically is a justifiable fix. Let's just hope I don't find a way to break banners further. 😉 Wait a minute... what's this? 👀 😅 ![Image](https://github.com/user-attachments/assets/da1ae21e-415c-484e-8394-5db4131271f2)

GiteaMirror commented

2026-04-19 23:11:26 -05:00

@Classic298 commented on GitHub (Jun 16, 2025):

at this point if you create so many banners as an admin, i think it's your own fault xD

@Classic298 commented on GitHub (Jun 16, 2025): at this point if you create so many banners as an admin, i think it's your own fault xD

GiteaMirror commented

2026-04-19 23:11:26 -05:00

@Classic298 commented on GitHub (Jun 16, 2025):

@silentoplayz what would be cool is if you could use \n as a newline in banners. Currently you can only use ** to make text bold, but not much more

@Classic298 commented on GitHub (Jun 16, 2025): @silentoplayz what would be cool is if you could use \n as a newline in banners. Currently you can only use ** to make text bold, but not much more

GiteaMirror commented

2026-04-19 23:11:28 -05:00

@Classic298 commented on GitHub (Jun 16, 2025):

@silentoplayz and one more for you: model descriptions:

if you create a description for a model with EMPTY newlines, it is correctly displayed if you hover over the (i) in the model selector

but if you hover over the model description in the actual landing page / chat screen, the empty new lines will not be rendered

@Classic298 commented on GitHub (Jun 16, 2025): @silentoplayz and one more for you: model descriptions: if you create a description for a model with EMPTY newlines, it is correctly displayed if you hover over the (i) in the model selector but if you hover over the model description in the actual landing page / chat screen, the empty new lines will not be rendered

GiteaMirror commented

2026-04-19 23:11:29 -05:00

@silentoplayz commented on GitHub (Jun 16, 2025):

at this point if you create so many banners as an admin, i think it's your own fault xD

Certainly, but I believe in every edge case needing tested.

what would be cool is if you could use \n as a newline in banners.

I can agree.

if you create a description for a model with EMPTY newlines, it is correctly displayed if you hover over the (i) in the model selector
but if you hover over the model description in the actual landing page / chat screen, the empty new lines will not be rendered

This is valid and has been around for a while (see attached screenshots for reference). Feel free to open a bug report or submit a fix PR for this. It seems even dashes (-) aren't being picked up for the model description on the landing/chat page.

@silentoplayz commented on GitHub (Jun 16, 2025): > at this point if you create so many banners as an admin, i think it's your own fault xD Certainly, but I believe in every edge case needing tested. > what would be cool is if you could use \n as a newline in banners. I can agree. > if you create a description for a model with EMPTY newlines, it is correctly displayed if you hover over the (i) in the model selector but if you hover over the model description in the actual landing page / chat screen, the empty new lines will not be rendered This is valid and has been around for a while (**see attached screenshots for reference**). Feel free to open a bug report or submit a fix PR for this. It seems even dashes (`-`) aren't being picked up for the model description on the landing/chat page. ![Image](https://github.com/user-attachments/assets/1f74408b-7562-46de-81a3-feee201f0764) ![Image](https://github.com/user-attachments/assets/ce06fff8-79b5-4c80-8215-1c08518b83f3)

GiteaMirror commented

2026-04-19 23:11:30 -05:00

@kns-12 commented on GitHub (Jun 30, 2025):

Hello @silentoplayz and @tjbck,

according to this issue, long banners are considered a "bug". And it has been fixed with a fixed height of "max-h-20" in commit afca606063
The fix is working and now we are having a problem that the banners are way too short.
In our team we have to add a banner which tells our members the do's and don'ts with open webui.

As you can see in the attached picture, the size of the banner is completely fine size-wise.

Compared to the new restricted height in open webui 0.6.15
We require multiple banners spanning further across the monitor. As well as looking rather bad in the UI.

In my opinion the new height restriction is too limiting and should be at least increased by a fair amount.
Banners are only set by admins and therefore should not be spanning the entire monitor.
If so this is clearly a missuse on the side of the admin.

Can you please look into that and maybe re-evaluate the change?

Greetings
kns

@kns-12 commented on GitHub (Jun 30, 2025): Hello @silentoplayz and @tjbck, according to this issue, long banners are considered a "bug". And it has been fixed with a fixed height of "max-h-20" in commit https://github.com/open-webui/open-webui/commit/afca606063900d0de46c1cb19ae8f58e7a8dfff0 The fix is working and now we are having a problem that the banners are way too short. In our team we have to add a banner which tells our members the do's and don'ts with open webui. As you can see in the attached picture, the size of the banner is completely fine size-wise. ![Image](https://github.com/user-attachments/assets/81f8f02b-29c7-42ad-980d-1999f478ae78) Compared to the new restricted height in open webui 0.6.15 We require multiple banners spanning further across the monitor. As well as looking rather bad in the UI. ![Image](https://github.com/user-attachments/assets/c0c1fa06-04d6-4e8b-96bf-aecac826f1bc) In my opinion the new height restriction is too limiting and should be at least increased by a fair amount. Banners are only set by admins and therefore should not be spanning the entire monitor. If so this is clearly a missuse on the side of the admin. Can you please look into that and maybe re-evaluate the change? Greetings kns

GiteaMirror commented

2026-04-19 23:11:31 -05:00

@silentoplayz commented on GitHub (Jun 30, 2025):

@kns-12 Banners only have a fixed height/size now, but the character count hasn't been limited AFAIK. Users can scroll using the mouse's scroll wheel on a banner to reveal text that isn't immediately displayed within it. Perhaps we could accommodate by increasing the height limit so that more text is immediately visible to the user within banners.

@silentoplayz commented on GitHub (Jun 30, 2025): @kns-12 Banners only have a fixed height/size now, but the character count hasn't been limited AFAIK. Users can scroll using the mouse's scroll wheel on a banner to reveal text that isn't immediately displayed within it. Perhaps we could accommodate by increasing the height limit so that more text is immediately visible to the user within banners.

GiteaMirror commented

2026-04-19 23:11:32 -05:00

@Mitsch164 commented on GitHub (Jun 30, 2025):

@silentoplayz Yes, users can scroll within the banner, but this isn't very obvious—especially in dark mode—and it's not particularly intuitive. As a result, we expect that most of our non-technical users won’t realize there's additional content to scroll after the heigth-limit. From our perspective, this change feels like a step back in terms of user experience.

@Mitsch164 commented on GitHub (Jun 30, 2025): @silentoplayz Yes, users can scroll within the banner, but this isn't very obvious—especially in dark mode—and it's not particularly intuitive. As a result, we expect that most of our non-technical users won’t realize there's additional content to scroll after the heigth-limit. From our perspective, this change feels like a step back in terms of user experience.

GiteaMirror commented

2026-04-19 23:11:33 -05:00

@silentoplayz commented on GitHub (Jun 30, 2025):

@silentoplayz Yes, users can scroll within the banner, but this isn't very obvious—especially in dark mode—and it's not particularly intuitive. As a result, we expect that most of our non-technical users won’t realize there's additional content to scroll after the heigth-limit. From our perspective, this change feels like a step back in terms of user experience.

I hope a463ef3c03 helps to alleviate needing to use so many banners for your use case!

@silentoplayz commented on GitHub (Jun 30, 2025): > [@silentoplayz](https://github.com/silentoplayz) Yes, users can scroll within the banner, but this isn't very obvious—especially in dark mode—and it's not particularly intuitive. As a result, we expect that most of our non-technical users won’t realize there's additional content to scroll after the heigth-limit. From our perspective, this change feels like a step back in terms of user experience. I hope **https://github.com/open-webui/open-webui/commit/a463ef3c03084aadb53dfbd329fcd1f7bacf28d6** helps to alleviate needing to use so many banners for your use case!

GiteaMirror referenced this issue

2026-04-20 00:28:57 -05:00

[GH-ISSUE #17435] issue: Changing localhost => somehost in Admin Settings is not saved #18283

GiteaMirror referenced this issue

2026-04-25 07:41:39 -05:00

[GH-ISSUE #17435] issue: Changing localhost => somehost in Admin Settings is not saved #33812

GiteaMirror referenced this issue

2026-05-05 20:16:52 -05:00

[GH-ISSUE #17435] issue: Changing localhost => somehost in Admin Settings is not saved #56949

Sign in to join this conversation.