[GH-ISSUE #24854] Filter outlet replacement content renders <details> as plain text instead of collapsible disclosure #123723

New Issue

GiteaMirror · 2026-05-21T03:11:47-05:00

GiteaMirror commented

2026-05-21 03:11:47 -05:00

Originally created by @gerpervaz on GitHub (May 17, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24854

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

Docker

Open WebUI Version

latest main/stable as of 2026-05-18

Ollama Version (if applicable)

N/A - using vLLM OpenAI-compatible backend

Operating System

Ubuntu Linux with Open WebUI running in Docker

Browser (if applicable)

Chromium-based browser; reproduced from the Ubuntu host browser as well

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

When a Filter replaces assistant message content in outlet with Markdown/HTML containing a standard <details><summary>...</summary>...</details> block, Open WebUI should render it as a collapsible disclosure, or clearly document/sanitize it consistently.

This is useful for audit trails in safety/validation filters: the main visible response can show a concise failure notice while the original blocked assistant content remains available in a collapsible audit section.

Actual Behavior

When the Filter replaces the assistant message content with a response containing a <details> block, Open WebUI renders the details section as plain text / non-collapsible content instead of a collapsible disclosure.

In my case, a Code Interpreter guard replaces an invalid assistant answer with a failure notice and appends an audit trail using <details>. The audit trail is preserved, but the <details> block does not behave as a collapsible element in the rendered assistant message.

Steps to Reproduce

Run Open WebUI from Docker using the latest available version.
Create a Filter with an outlet that replaces the final assistant message content.
In the replacement content, include a standard HTML details block:

<details>
<summary>Audit: original blocked response</summary>

Original assistant content goes here.

</details>

Trigger the filter in a chat so that the assistant message is replaced by this content.
Observe the rendered assistant message.

Minimal filter example:

async def outlet(self, body, __user__=None):
    messages = body.get("messages", [])
    assistant = next((m for m in reversed(messages) if m.get("role") == "assistant"), None)
    if assistant:
        assistant["content"] = """
Main replacement text.

<details>
<summary>Audit: original blocked response</summary>

Original assistant content goes here.

</details>
"""
    return body

The same happens in a real-world filter that appends an audit trail after blocking failed Code Interpreter / Native execute_code output.

Logs & Screenshots

No backend crash is involved. The replacement content is persisted and visible, but the <details> section is not rendered as a collapsible disclosure.

This is related to, but distinct from, Issue #24852. That issue is about the first assistant message not being visually updated by outlet events under Native tool calling + streaming. This issue is specifically about Markdown/HTML rendering of <details> in Filter replacement content once the replacement is visible.

A screenshot can be attached showing the audit section rendered as non-collapsible text.

Additional Information

Use case: a safety filter validates Code Interpreter / Native execute_code results. When execution fails, the filter replaces the final answer with a concise failure notice and appends an audit trail containing the original blocked assistant content.

A collapsible <details> block is useful because the original content can be long. Without collapsible rendering, the audit trail makes the message very noisy.

This is not a model/tool-calling problem; it should be reproducible with a minimal outlet replacement. If Open WebUI intentionally sanitizes or disables <details> in assistant Markdown, please document the recommended supported pattern for collapsible audit/debug sections generated by Filters.

Originally created by @gerpervaz on GitHub (May 17, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/24854 ### 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 Docker ### Open WebUI Version latest main/stable as of 2026-05-18 ### Ollama Version (if applicable) N/A - using vLLM OpenAI-compatible backend ### Operating System Ubuntu Linux with Open WebUI running in Docker ### Browser (if applicable) Chromium-based browser; reproduced from the Ubuntu host browser as well ### 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 When a Filter replaces assistant message content in `outlet` with Markdown/HTML containing a standard `<details><summary>...</summary>...</details>` block, Open WebUI should render it as a collapsible disclosure, or clearly document/sanitize it consistently. This is useful for audit trails in safety/validation filters: the main visible response can show a concise failure notice while the original blocked assistant content remains available in a collapsible audit section. ### Actual Behavior When the Filter replaces the assistant message content with a response containing a `<details>` block, Open WebUI renders the details section as plain text / non-collapsible content instead of a collapsible disclosure. In my case, a Code Interpreter guard replaces an invalid assistant answer with a failure notice and appends an audit trail using `<details>`. The audit trail is preserved, but the `<details>` block does not behave as a collapsible element in the rendered assistant message. ### Steps to Reproduce 1. Run Open WebUI from Docker using the latest available version. 2. Create a Filter with an `outlet` that replaces the final assistant message content. 3. In the replacement content, include a standard HTML details block: ```html <details> <summary>Audit: original blocked response</summary> Original assistant content goes here. </details> ``` 4. Trigger the filter in a chat so that the assistant message is replaced by this content. 5. Observe the rendered assistant message. Minimal filter example: ```python async def outlet(self, body, __user__=None): messages = body.get("messages", []) assistant = next((m for m in reversed(messages) if m.get("role") == "assistant"), None) if assistant: assistant["content"] = """ Main replacement text. <details> <summary>Audit: original blocked response</summary> Original assistant content goes here. </details> """ return body ``` The same happens in a real-world filter that appends an audit trail after blocking failed Code Interpreter / Native `execute_code` output. ### Logs & Screenshots No backend crash is involved. The replacement content is persisted and visible, but the `<details>` section is not rendered as a collapsible disclosure. This is related to, but distinct from, Issue #24852. That issue is about the first assistant message not being visually updated by outlet events under Native tool calling + streaming. This issue is specifically about Markdown/HTML rendering of `<details>` in Filter replacement content once the replacement is visible. A screenshot can be attached showing the audit section rendered as non-collapsible text. ### Additional Information Use case: a safety filter validates Code Interpreter / Native `execute_code` results. When execution fails, the filter replaces the final answer with a concise failure notice and appends an audit trail containing the original blocked assistant content. A collapsible `<details>` block is useful because the original content can be long. Without collapsible rendering, the audit trail makes the message very noisy. This is not a model/tool-calling problem; it should be reproducible with a minimal outlet replacement. If Open WebUI intentionally sanitizes or disables `<details>` in assistant Markdown, please document the recommended supported pattern for collapsible audit/debug sections generated by Filters.

GiteaMirror added the bug label 2026-05-21 03:11:47 -05:00

GiteaMirror commented

2026-05-21 03:11:50 -05:00

@owui-terminator[bot] commented on GitHub (May 17, 2026):

⚠️ Missing Issue Title Prefix

@gerpervaz, your issue title is missing a categorising prefix (e.g. bug:, feat:, docs:).

Please update the title to lead with one of:

bug: bug report or error
feat: feature request or enhancement
docs: documentation issue
question: usage question
help: support request

Example: bug: Login fails when the password contains special characters

@owui-terminator[bot] commented on GitHub (May 17, 2026): # ⚠️ Missing Issue Title Prefix @gerpervaz, your issue title is missing a categorising prefix (e.g. `bug:`, `feat:`, `docs:`). Please update the title to lead with one of: - **bug**: bug report or error - **feat**: feature request or enhancement - **docs**: documentation issue - **question**: usage question - **help**: support request Example: `bug: Login fails when the password contains special characters`

GiteaMirror commented

2026-05-21 03:11:50 -05:00

@owui-terminator[bot] commented on GitHub (May 17, 2026):

🔍 Related Issues Found

I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions:

🟣 #24635 issue:
tag not rendered, displayed as raw text
This is the closest match: it reports <details type="reasoning"> being shown as raw text instead of a collapsible disclosure. The underlying rendering/parsing problem for <details> blocks is the same class of issue as the filter-generated <details> content here.
by siriusa51
🟣 #24634 issue:
tag not rendered, displayed as raw text
This issue covers <details type="tool_calls"> not rendering as collapsible UI and instead appearing as raw text. While the specific source is model tool-call output rather than a Filter, it strongly overlaps with the same <details> rendering path.
by sharyuke
🟣 #21860 issue: Inconsistent HTML Rendering: Escaped in Chat, Rendered in Notification
This reports inconsistent HTML rendering between chat and notification surfaces, showing that Open WebUI handles HTML differently across UI paths. It is less specific, but still relevant to the question of whether HTML like <details> is intentionally rendered or sanitized.
by Mywk · bug

💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead.

This comment was generated automatically. React with 👍 if helpful, 👎 if not.

@owui-terminator[bot] commented on GitHub (May 17, 2026):  🔍 **Related Issues Found** I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions: 1. 🟣 [#24635](https://github.com/open-webui/open-webui/issues/24635) **issue: <details type="reasoning"> tag not rendered, displayed as raw text** *This is the closest match: it reports `<details type="reasoning">` being shown as raw text instead of a collapsible disclosure. The underlying rendering/parsing problem for `<details>` blocks is the same class of issue as the filter-generated `<details>` content here.* *by siriusa51* 2. 🟣 [#24634](https://github.com/open-webui/open-webui/issues/24634) **issue: <details type="tool_calls"> tag not rendered, displayed as raw text** *This issue covers `<details type="tool_calls">` not rendering as collapsible UI and instead appearing as raw text. While the specific source is model tool-call output rather than a Filter, it strongly overlaps with the same `<details>` rendering path.* *by sharyuke* 3. 🟣 [#21860](https://github.com/open-webui/open-webui/issues/21860) **issue: Inconsistent HTML Rendering: Escaped in Chat, Rendered in Notification** *This reports inconsistent HTML rendering between chat and notification surfaces, showing that Open WebUI handles HTML differently across UI paths. It is less specific, but still relevant to the question of whether HTML like `<details>` is intentionally rendered or sanitized.* *by Mywk · `bug`* --- 💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead. *This comment was generated automatically.* React with 👍 if helpful, 👎 if not.

GiteaMirror commented

2026-05-21 03:11:51 -05:00

@gerpervaz commented on GitHub (May 21, 2026):

Thanks, I checked the related issues.

#24634 and #24635 are definitely close and likely share the same underlying <details> rendering/parsing path. If the fix is in the Markdown/custom-details rendering pipeline, it may also fix this case.

That said, I think this issue still adds a useful reproduction path because it is not model-generated <details type="reasoning"> or <details type="tool_calls"> output. It is content produced by a Filter outlet replacement. That matters because Filter authors may intentionally return Markdown/HTML audit trails, and in this case even a well-formed standard <details><summary>...</summary>...</details> block from the outlet replacement is rendered as plain text / non-collapsible content.

#21860 seems broader and already completed around inconsistent chat vs notification HTML rendering, so I do not think it fully covers this Filter/outlet route.

If maintainers prefer a single canonical tracking item, I am happy for this to be linked or closed in favor of the #24634 discussion, but I wanted to keep the Filter/outlet reproduction visible because it may exercise a different rendering path than direct model output.

@gerpervaz commented on GitHub (May 21, 2026): Thanks, I checked the related issues. #24634 and #24635 are definitely close and likely share the same underlying `<details>` rendering/parsing path. If the fix is in the Markdown/custom-details rendering pipeline, it may also fix this case. That said, I think this issue still adds a useful reproduction path because it is not model-generated `<details type="reasoning">` or `<details type="tool_calls">` output. It is content produced by a Filter `outlet` replacement. That matters because Filter authors may intentionally return Markdown/HTML audit trails, and in this case even a well-formed standard `<details><summary>...</summary>...</details>` block from the outlet replacement is rendered as plain text / non-collapsible content. #21860 seems broader and already completed around inconsistent chat vs notification HTML rendering, so I do not think it fully covers this Filter/outlet route. If maintainers prefer a single canonical tracking item, I am happy for this to be linked or closed in favor of the #24634 discussion, but I wanted to keep the Filter/outlet reproduction visible because it may exercise a different rendering path than direct model output.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#123723