github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-06-03 07:24:59 -05:00
Code Issues 2.4k Packages Projects Releases 129 Wiki Activity

[GH-ISSUE #20602] issue: Allow external link navigation from WebUI (configurable) – ERR_BLOCKED_BY_RESPONSE when opening YouTube from tool UI #122544

New Issue
Closed
opened 2026-05-21 01:24:54 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-05-21 01:24:54 -05:00
Owner
Copy Link

Originally created by @dhaern on GitHub (Jan 12, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/20602

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

Pip Install

Open WebUI Version

0.7.2

Ollama Version (if applicable)

No response

Operating System

Ubuntu 24.04

Browser (if applicable)

Zen, Snap Chromium for ARM64

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

Clicking a clean external URL in a tool UI should open the target in a new tab without being blocked.

Actual Behavior

External navigation is blocked by browser (ERR_BLOCKED_BY_RESPONSE), even when headers are permissive.

Important detail: Regular links rendered in normal assistant text work fine.
The block only happens when the link is inside a tool UI component (HTMLResponse/embedded UI). So the problem appears tied to the UI component renderer/router, not to general link handling.

Steps to Reproduce

When a tool returns an embedded UI (HTMLResponse/iframe), any external link clicked inside the WebUI context is blocked with:

www.youtube.com is blocked
www.youtube.com refused to connect.
ERR_BLOCKED_BY_RESPONSE

This happens even with a clean URL like:
https://www.youtube.com/watch?v=VIDEO_ID

If I copy the exact same URL and open it in a fresh tab or duplicate the tab, it works.
So the URL itself is valid; the navigation initiated from the OWUI context is blocked.

Logs & Screenshots

Hypothesis
OWUI front-end SPA may intercept external link navigation (or force internal routing) in a way that triggers browser blocking (ERR_BLOCKED_BY_RESPONSE). This appears unrelated to COOP/CSP now.

Additional Information

What I tried:

  • rel="noopener noreferrer"
  • referrerpolicy="no-referrer"
  • COOP: unsafe-none
  • No CSP headers
  • Data URL + meta refresh
  • window.open('about:blank') + opener = null
  • form GET with target="_blank"

Using this tool Youtube search and embed

Request
Please add a user-level setting (or global setting) to:

  • allow external link navigation from WebUI context, or
  • bypass the internal router for external links (force real navigation), or
  • provide a safe “open external link” handler that avoids ERR_BLOCKED_BY_RESPONSE.

Even a toggle like:
Allow external navigation from tool outputs (UI components) would solve this.

Originally created by @dhaern on GitHub (Jan 12, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/20602 ### 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 Pip Install ### Open WebUI Version 0.7.2 ### Ollama Version (if applicable) _No response_ ### Operating System Ubuntu 24.04 ### Browser (if applicable) Zen, Snap Chromium for ARM64 ### 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 Clicking a clean external URL in a tool UI should open the target in a new tab without being blocked. ### Actual Behavior External navigation is blocked by browser (ERR_BLOCKED_BY_RESPONSE), even when headers are permissive. Important detail: Regular links rendered in normal assistant text work fine. The block only happens when the link is inside a tool UI component (HTMLResponse/embedded UI). So the problem appears tied to the UI component renderer/router, not to general link handling. ### Steps to Reproduce When a tool returns an embedded UI (HTMLResponse/iframe), any external link clicked inside the WebUI context is blocked with: www.youtube.com is blocked www.youtube.com refused to connect. ERR_BLOCKED_BY_RESPONSE This happens even with a clean URL like: https://www.youtube.com/watch?v=VIDEO_ID If I copy the exact same URL and open it in a fresh tab or duplicate the tab, it works. So the URL itself is valid; the navigation initiated from the OWUI context is blocked. ### Logs & Screenshots Hypothesis OWUI front-end SPA may intercept external link navigation (or force internal routing) in a way that triggers browser blocking (ERR_BLOCKED_BY_RESPONSE). This appears unrelated to COOP/CSP now. ### Additional Information What I tried: - rel="noopener noreferrer" - referrerpolicy="no-referrer" - COOP: unsafe-none - No CSP headers - Data URL + meta refresh - window.open('about:blank') + opener = null - form GET with target="_blank" Using this tool [Youtube search and embed](https://github.com/Haervwe/open-webui-tools/blob/main/tools/youtube_search_tool.py) Request Please add a user-level setting (or global setting) to: - allow external link navigation from WebUI context, or - bypass the internal router for external links (force real navigation), or - provide a safe “open external link” handler that avoids ERR_BLOCKED_BY_RESPONSE. Even a toggle like: Allow external navigation from tool outputs (UI components) would solve this.
GiteaMirror added the bug label 2026-05-21 01:24:54 -05:00
GiteaMirror commented 2026-05-21 01:25:01 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Jan 12, 2026):

@silentoplayz can you reproduce? I think this is a matter of the existing settings in the interface settings

<!-- gh-comment-id:3737223687 --> @Classic298 commented on GitHub (Jan 12, 2026): @silentoplayz can you reproduce? I think this is a matter of the existing settings in the interface settings
GiteaMirror commented 2026-05-21 01:25:02 -05:00
Author
Owner
Copy Link

@dhaern commented on GitHub (Jan 12, 2026):

@silentoplayz can you reproduce? I think this is a matter of the existing settings in the interface settings

I already tried in user settings:

Detect Artifacts Automatically ON and OFF

iframe Sandbox Allow Same Origin ON and OFF

iframe Sandbox Allow Forms ON and OFF

Web Search (prob useless but I tried) Default and Always

And redirects from that youtube search and embed tool are blocked aswell.

I am running Open WebUI on an Oracle Cloud Infrastructure (OCI) ARM64 VPS, managed as a systemd service. The instance is exposed to the internet via Caddy (reverse proxy) using a DuckDNS domain. I access the WebUI remotely from my local Windows 11 machine.

<!-- gh-comment-id:3739164738 --> @dhaern commented on GitHub (Jan 12, 2026): > [@silentoplayz](https://github.com/silentoplayz) can you reproduce? I think this is a matter of the existing settings in the interface settings I already tried in user settings: Detect Artifacts Automatically ON and OFF iframe Sandbox Allow Same Origin ON and OFF iframe Sandbox Allow Forms ON and OFF Web Search (prob useless but I tried) Default and Always And redirects from that youtube search and embed tool are blocked aswell. I am running Open WebUI on an Oracle Cloud Infrastructure (OCI) ARM64 VPS, managed as a systemd service. The instance is exposed to the internet via Caddy (reverse proxy) using a DuckDNS domain. I access the WebUI remotely from my local Windows 11 machine.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
confirmed
confirmed issue
core
documentation
enhancement
good first issue
help wanted
non-core
pull-request
Mirrored from GitHub Pull Request
 python
question
testing wanted
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#122544
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?