[GH-ISSUE #20890] issue: WebUI stalls sending 'completions' requests when switching to another browser tab #106318

New Issue

GiteaMirror · 2026-05-18T04:36:03-05:00

GiteaMirror commented

2026-05-18 04:36:03 -05:00

Originally created by @fnf on GitHub (Jan 23, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/20890

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

Windows 11

Browser (if applicable)

Firefox, Chrome, Edge, Opera (all latest versions)

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

Some prompts are expected to take a long time for the LLM to process, what I'd normally do is I send a prompt (by pressing Ctrl-Enter or clicking the 'Send message' button in the WebUI): I'd immediately switch to another tab to do something else whilst waiting for the prompt to come back.

I'd expect the prompt (specifically the POST 'completions' request) to be sent to the server, regardless of whether the browser tab is visible/active, or is in the background.

Actual Behavior

The prompt is never sent unless I switch back to the WebUI tab.

Steps to Reproduce

This issue has been reproduced in both Open WebUI pip installation, as well as Docker installation (inside WSL2 on Arch Linux, on Windows 11).

This has also been reproduced in multiple main-stream browsers: Firefox, Chrome, Edge and Opera.

I've also fiddled with browser settings related to power/CPU load management, as well as some extensions to force browser tabs being active even when they're switched to the background (such as Always Active Window on Firefox and Chrome/Edge).

I've also analysed the Network activity and could confirm that it was the WebUI that stalls sending the POST 'completions' requests, and not the WebUI server or the LLM server.

The steps to reproduce are as follows:

Pick a model that usually takes a few seconds or longer to respond.
Send a message (anything will do, such as 'hello')
After sending the message, immediately switch to another browser tab (I'd usually use Ctrl-Tab)
- The issue is clealy visible if the Web Developer Tools->Network tab is open to confirm the behaviour of the WebUI client.
The WebUI client won't send the prompt to the server (it will stall forever) and only do so once we switch back to WebUI browser tab. When we switch back, it'd normally take 10-20 seconds to realise that we've switched back and will only POST the prompt at this point.
- If the browser tab is kept in the foreground i.e., we don't switch to another tab, then the prompt is usually POST'ed in 5-7 seconds.

Logs & Screenshots

This could be a little hard to see, but this screenshot shows the moment I sent the message:

After that, I switched to another browser tab for about 20 seconds then switched back. This screenshot shows that the completions POST request was only sent by that point:

The prompt would be stalled indefinitely as long as I don't switch back to the WebUI tab.

Additional Information

My workaround for this issue is to remain in the WebUI browser tab for at least 10 seconds after sending the prompt, because we can't see when the completions message is POST'ed by the client unless we analyse the network traffic.

Originally created by @fnf on GitHub (Jan 23, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/20890 ### 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 Windows 11 ### Browser (if applicable) Firefox, Chrome, Edge, Opera (all latest versions) ### 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 Some prompts are expected to take a long time for the LLM to process, what I'd normally do is I send a prompt (by pressing Ctrl-Enter or clicking the 'Send message' button in the WebUI): I'd immediately switch to another tab to do something else whilst waiting for the prompt to come back. I'd expect the prompt (specifically the POST 'completions' request) to be sent to the server, regardless of whether the browser tab is visible/active, or is in the background. ### Actual Behavior The prompt is never sent unless I switch back to the WebUI tab. ### Steps to Reproduce This issue has been reproduced in both Open WebUI pip installation, as well as Docker installation (inside WSL2 on Arch Linux, on Windows 11). This has also been reproduced in multiple main-stream browsers: Firefox, Chrome, Edge and Opera. I've also fiddled with browser settings related to power/CPU load management, as well as some extensions to force browser tabs being active even when they're switched to the background (such as Always Active Window on Firefox and Chrome/Edge). I've also analysed the Network activity and could confirm that it was the WebUI that stalls sending the POST 'completions' requests, and not the WebUI server or the LLM server. The steps to reproduce are as follows: - Pick a model that usually takes a few seconds or longer to respond. - Send a message (anything will do, such as 'hello') - After sending the message, immediately switch to another browser tab (I'd usually use Ctrl-Tab) + The issue is clealy visible if the Web Developer Tools->Network tab is open to confirm the behaviour of the WebUI client. - The WebUI client won't send the prompt to the server (it will stall forever) and only do so once we switch back to WebUI browser tab. When we switch back, it'd normally take 10-20 seconds to realise that we've switched back and will only POST the prompt at this point. + If the browser tab is kept in the foreground i.e., we don't switch to another tab, then the prompt is usually POST'ed in 5-7 seconds. ### Logs & Screenshots This could be a little hard to see, but this screenshot shows the moment I sent the message: <img width="1790" height="974" alt="Image" src="https://github.com/user-attachments/assets/3be8ba21-ff76-4371-8385-8d9dfb0b33a1" /> After that, I switched to another browser tab for about 20 seconds then switched back. This screenshot shows that the completions POST request was only sent by that point: <img width="1787" height="972" alt="Image" src="https://github.com/user-attachments/assets/62ed96f7-44a5-4bee-90dd-2ef8eef707b7" /> The prompt would be stalled indefinitely as long as I don't switch back to the WebUI tab. ### Additional Information My workaround for this issue is to remain in the WebUI browser tab for at least 10 seconds after sending the prompt, because we can't see when the `completions` message is POST'ed by the client unless we analyse the network traffic.

GiteaMirror added the bug label 2026-05-18 04:36:03 -05:00

GiteaMirror closed this issue

2026-05-18 04:36:04 -05:00

GiteaMirror commented

2026-05-18 04:36:06 -05:00

@owui-terminator[bot] commented on GitHub (Jan 23, 2026):

🔍 Similar Issues Found

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

#20196 Open WebUI hangs streaming when pipe returns AsyncGenerator (UI stuck “executing”)
by dhaern • Dec 27, 2025 • bug
#20502 issue: Performance Optimization: How can open-webui support high availability and high concurrency?
by gongshaojie12 • Jan 09, 2026 • bug
#20327 issue: Unable to use any Open WebUI version newer than 0.6.25 due to hybrid search performance
by galvanoid • Jan 02, 2026 • bug
#16143 issue: Open-WebUI stopped opening all of a sudden
by venki-lfc • Jul 30, 2025 • bug

💡 Tips:

If this is a duplicate, please consider closing this issue and adding any additional details to the existing one
If you found a solution in any of these issues, please share it here to help others

This comment was generated automatically by a bot. Please react with a 👍 if this comment was helpful, or a 👎 if it was not.

@owui-terminator[bot] commented on GitHub (Jan 23, 2026): 🔍 **Similar Issues Found** I found some existing issues that might be related to this one. Please check if any of these are duplicates or contain helpful solutions: 1. [#20196](https://github.com/open-webui/open-webui/issues/20196) **Open WebUI hangs streaming when pipe returns AsyncGenerator (UI stuck “executing”)** *by dhaern • Dec 27, 2025 • `bug`* 2. [#20502](https://github.com/open-webui/open-webui/issues/20502) **issue: Performance Optimization: How can open-webui support high availability and high concurrency?** *by gongshaojie12 • Jan 09, 2026 • `bug`* 3. [#20327](https://github.com/open-webui/open-webui/issues/20327) **issue: Unable to use any Open WebUI version newer than 0.6.25 due to hybrid search performance** *by galvanoid • Jan 02, 2026 • `bug`* 4. [#16143](https://github.com/open-webui/open-webui/issues/16143) **issue: Open-WebUI stopped opening all of a sudden** *by venki-lfc • Jul 30, 2025 • `bug`* --- 💡 **Tips:** - If this is a duplicate, please consider closing this issue and adding any additional details to the existing one - If you found a solution in any of these issues, please share it here to help others *This comment was generated automatically by a bot.* Please react with a 👍 if this comment was helpful, or a 👎 if it was not.

GiteaMirror commented

2026-05-18 04:36:07 -05:00

@Classic298 commented on GitHub (Feb 6, 2026):

tested on Brave, cannot reproduce

@Classic298 commented on GitHub (Feb 6, 2026): tested on Brave, cannot reproduce

GiteaMirror commented

2026-05-18 04:36:07 -05:00

@Classic298 commented on GitHub (Feb 6, 2026):

i sent hello to a model in a fresh conversation and INSTANTLY switched away with CTRL+TAB

then waited 10 sec and returned and the completion was already done and network looked normal to me

@Classic298 commented on GitHub (Feb 6, 2026): i sent hello to a model in a fresh conversation and INSTANTLY switched away with CTRL+TAB then waited 10 sec and returned and the completion was already done and network looked normal to me

GiteaMirror commented

2026-05-18 04:36:08 -05:00

@fnf commented on GitHub (Feb 7, 2026):

@Classic298 Thanks for having look.

I found out that the delay was actually caused by the Location update step, which blocked completions request. It was not the completions request that took a long time to get POSTed.

When I used my normal account, it again about 7 seconds for the update step to take place, followed quickly by the completions request:

Once Allow User Location was disabled, the latency became minimal again :) . I'll change the title of this ticket.

@fnf commented on GitHub (Feb 7, 2026): @Classic298 Thanks for having look. I found out that the delay was actually caused by the Location update step, which blocked `completions` request. It was not the `completions` request that took a long time to get POSTed. When I used my normal account, it again about 7 seconds for the `update` step to take place, followed quickly by the `completions` request: <img width="2520" height="494" alt="Image" src="https://github.com/user-attachments/assets/04c711dd-3c60-4c65-b020-9f3e975e6e6c" /> Once `Allow User Location` was disabled, the latency became minimal again :) . I'll change the title of this ticket.

GiteaMirror commented

2026-05-18 04:36:09 -05:00

@fnf commented on GitHub (Feb 7, 2026):

Actually, I'd like to keep the title as-it, because even if location update takes a long time, it shouldn't cause completions to completely stall. Would it be possible for you to try enabling Allow User Location to see if it's reproducible?.

I don't actually need this feature, but it might have uncovered an issue here.

@fnf commented on GitHub (Feb 7, 2026): Actually, I'd like to keep the title as-it, because even if location update takes a long time, it shouldn't cause `completions` to completely stall. Would it be possible for you to try enabling `Allow User Location` to see if it's reproducible?. I don't actually need this feature, but it might have uncovered an issue here.

GiteaMirror commented

2026-05-18 04:36:09 -05:00

@Classic298 commented on GitHub (Feb 7, 2026):

Are you sure this is not a browser limitation?

From a security perspective it seems... bad to allow not-focused browser tabs to request your location.
So to me it would make sense that the location update is stalled while the tab is not focused. And since the chat completion in your case depends on the location being fetched,... anyways let me research if my assumptions here are correct or not

@Classic298 commented on GitHub (Feb 7, 2026): Are you sure this is not a browser limitation? From a security perspective it seems... bad to allow not-focused browser tabs to request your location. So to me it would make sense that the location update is stalled while the tab is not focused. And since the chat completion in your case depends on the location being fetched,... anyways let me research if my assumptions here are correct or not

GiteaMirror commented

2026-05-18 04:36:12 -05:00

@Classic298 commented on GitHub (Feb 7, 2026):

Ok i did some research.

Modern browsers indeed block geolocation updates (and many other things) when a browser tab is not in focus, for two main reasons

performance optimization - a tab that is not focsued should not use complex APIs
privacy - as i suspected: allowing background tabs to constantly query the location would be a privacy nightmare.

So if you are using the User Location feature to send your location to the model - you will need to keep the browser tab focused until the location is determined.

How else is Open WebUI supposed to handle it in these cases?

You want to use the location feature to send the location to the model - so Open WebUI has to query your location prior to sending off the prompt to the model - but you switched tabs and now the API does not let the out-of-focus tab query the location anymore - and no location = no prompt gets sent off.

@Classic298 commented on GitHub (Feb 7, 2026): Ok i did some research. Modern browsers indeed block geolocation updates (and many other things) when a browser tab is not in focus, for two main reasons - performance optimization - a tab that is not focsued should not use complex APIs - privacy - as i suspected: allowing background tabs to constantly query the location would be a privacy nightmare. So if you are using the User Location feature to send your location to the model - you will need to keep the browser tab focused until the location is determined. How else is Open WebUI supposed to handle it in these cases? You want to use the location feature to send the location to the model - so Open WebUI has to query your location prior to sending off the prompt to the model - but you switched tabs and now the API does not let the out-of-focus tab query the location anymore - and no location = no prompt gets sent off.

GiteaMirror commented

2026-05-18 04:36:14 -05:00

@fnf commented on GitHub (Feb 7, 2026):

Yes, it wasn't immediately apparent what the update request did until I looked at the response. Once I knew it was location update it made sense why there was such a long delay.

Before this, I spent a fair amount of time checking and configuring both Firefox and Chrome to disallow tabs going to sleep. Also tried several addons to keep browser tabs alive (as mentioned in the description). The assumption was that background tabs were performance-throttled.

privacy - as i suspected: allowing background tabs to constantly query the location would be a privacy nightmare.

I think it would probably have been fine for background tabs to query locations within the time it was allowed to be active (Firefox's default is 1 minute). Anyway, this is a browser's policy and not an issue with Open WebUI itself.

I've been fighting this issue for quite a while so happy that it's now working :) .

@fnf commented on GitHub (Feb 7, 2026): Yes, it wasn't immediately apparent what the `update` request did until I looked at the response. Once I knew it was location update it made sense why there was such a long delay. Before this, I spent a fair amount of time checking and configuring both Firefox and Chrome to disallow tabs going to sleep. Also tried several addons to keep browser tabs alive (as mentioned in the description). The assumption was that background tabs were performance-throttled. > privacy - as i suspected: allowing background tabs to constantly query the location would be a privacy nightmare. I think it would probably have been fine for background tabs to query locations within the time it was allowed to be active (Firefox's default is 1 minute). Anyway, this is a browser's policy and not an issue with Open WebUI itself. I've been fighting this issue for quite a while so happy that it's now working :) .

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#106318