github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-05-07 11:28:35 -05:00
Code Issues 1.3k Packages Projects Releases 126 Wiki Activity

bug: "Allow User Location" shouldn't be synced. #2190

New Issue
Closed
opened 2025-11-11 15:02:01 -06:00 by GiteaMirror · 10 comments
GiteaMirror commented 2025-11-11 15:02:01 -06:00
Owner
Copy Link

Originally created by @sebdanielsson on GitHub (Sep 24, 2024).

Bug Report

Installation Method

Not relevant.

Environment

  • Open WebUI Version: v0.3.28

  • Operating System: macOS Sequoia & Windows 11

  • Browser (if applicable): Any. Tested with Arc and Safari.

Confirmation:

  • I have read and followed all the instructions provided in the README.md.
  • I am on 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 the exact steps to reproduce the bug in the "Steps to Reproduce" section below.

Expected Behavior:

Being able to start a chat.

Actual Behavior:

"Uh-oh! There was an issue connecting to gpt-4o-mini-2024-07-18."

Description

Bug Summary:
If starting a chat on a browser where location access isn't enabled. A chat can't be started, even when location variables in system prompt is not present. This makes it impossible to use the same account on two different computers if location access is not allowed on any of them. Even when not using location data in the chat.

Reproduction Details

Steps to Reproduce:

  1. Login to Open WebUI on computer A where location access is enabled for the browser (in my case macOS and Arc/Safari).
  2. Login to Open WebUI on computer B where location access is not allowed (Windows Settings > Privacy and Security > Location). In my case Windows 11 and Arc.
  3. Enable "Allow User Location" in Open WebUI settings on computer A.
  4. Start a chat on computer A.
  5. Continue the chat on computer B and see the error message.

Logs and Screenshots

Browser Console Logs:

Help.DrnJdJJD.js:147 submitPrompt 
2UserMessage.svelte:85 UserMessage mounted
ResponseMessage.svelte:325 ResponseMessage mounted
Help.DrnJdJJD.js:147 modelId gpt-4o-mini-2024-07-18
Help.DrnJdJJD.js:148 null
index.ts:370 Error getting user location: GeolocationPositionError {code: 2, message: ''}
(anonymous) @ index.ts:370
Promise.catch
re @ index.ts:369
R @ index.ts:259
Kt @ Help.DrnJdJJD.js:154
await in Kt
(anonymous) @ Help.DrnJdJJD.js:148
await in (anonymous)
Ot @ Help.DrnJdJJD.js:147
await in Ot
Nt @ Help.DrnJdJJD.js:147
await in Nt
Kt @ Help.DrnJdJJD.js:47
Help.DrnJdJJD.js:158 GeolocationPositionError {code: 2, message: ''}code: 2message: ""[[Prototype]]: GeolocationPositionErrorPERMISSION_DENIED: 1POSITION_UNAVAILABLE: 2TIMEOUT: 3code: (...)message: (...)constructor: ƒ GeolocationPositionError()Symbol(Symbol.toStringTag): "GeolocationPositionError"get code: ƒ code()get message: ƒ message()[[Prototype]]: Object
_e @ Help.DrnJdJJD.js:158
Kt @ Help.DrnJdJJD.js:158
await in Kt
(anonymous) @ Help.DrnJdJJD.js:148
await in (anonymous)
Ot @ Help.DrnJdJJD.js:147
await in Ot
Nt @ Help.DrnJdJJD.js:147
await in Nt
Kt @ Help.DrnJdJJD.js:47
+layout.svelte:82 usage {models: Array(1)}
+layout.svelte:82 usage {models: Array(1)}
+layout.svelte:82 usage {models: Array(0)}

Docker Container Logs:

Screenshots/Screen Recordings (if applicable):
image

Additional Information

  1. In my opinion, location access should be set locally in localStorage instead of being synced between all sessions. This way a user can have location access enabled on some devices and disabled on others.
  2. If location variables are not used in slash prompts or system prompts location access shuldn't be checked by Open WebUI since it won't be used during the conversation.
Originally created by @sebdanielsson on GitHub (Sep 24, 2024). # Bug Report ## Installation Method Not relevant. ## Environment - **Open WebUI Version:** v0.3.28 - **Operating System:** macOS Sequoia & Windows 11 - **Browser (if applicable):** Any. Tested with Arc and Safari. **Confirmation:** - [x] I have read and followed all the instructions provided in the README.md. - [x] I am on the latest version of both Open WebUI and Ollama. - [ ] I have included the browser console logs. - [ ] I have included the Docker container logs. - [x] I have provided the exact steps to reproduce the bug in the "Steps to Reproduce" section below. ## Expected Behavior: Being able to start a chat. ## Actual Behavior: "Uh-oh! There was an issue connecting to gpt-4o-mini-2024-07-18." ## Description **Bug Summary:** If starting a chat on a browser where location access isn't enabled. A chat can't be started, even when location variables in system prompt is not present. This makes it impossible to use the same account on two different computers if location access is not allowed on any of them. Even when not using location data in the chat. ## Reproduction Details **Steps to Reproduce:** 1. Login to Open WebUI on computer A where location access is enabled for the browser (in my case macOS and Arc/Safari). 2. Login to Open WebUI on computer B where location access is not allowed (Windows Settings > Privacy and Security > Location). In my case Windows 11 and Arc. 3. Enable "Allow User Location" in Open WebUI settings on computer A. 4. Start a chat on computer A. 5. Continue the chat on computer B and see the error message. ## Logs and Screenshots **Browser Console Logs:** ``` Help.DrnJdJJD.js:147 submitPrompt 2UserMessage.svelte:85 UserMessage mounted ResponseMessage.svelte:325 ResponseMessage mounted Help.DrnJdJJD.js:147 modelId gpt-4o-mini-2024-07-18 Help.DrnJdJJD.js:148 null index.ts:370 Error getting user location: GeolocationPositionError {code: 2, message: ''} (anonymous) @ index.ts:370 Promise.catch re @ index.ts:369 R @ index.ts:259 Kt @ Help.DrnJdJJD.js:154 await in Kt (anonymous) @ Help.DrnJdJJD.js:148 await in (anonymous) Ot @ Help.DrnJdJJD.js:147 await in Ot Nt @ Help.DrnJdJJD.js:147 await in Nt Kt @ Help.DrnJdJJD.js:47 Help.DrnJdJJD.js:158 GeolocationPositionError {code: 2, message: ''}code: 2message: ""[[Prototype]]: GeolocationPositionErrorPERMISSION_DENIED: 1POSITION_UNAVAILABLE: 2TIMEOUT: 3code: (...)message: (...)constructor: ƒ GeolocationPositionError()Symbol(Symbol.toStringTag): "GeolocationPositionError"get code: ƒ code()get message: ƒ message()[[Prototype]]: Object _e @ Help.DrnJdJJD.js:158 Kt @ Help.DrnJdJJD.js:158 await in Kt (anonymous) @ Help.DrnJdJJD.js:148 await in (anonymous) Ot @ Help.DrnJdJJD.js:147 await in Ot Nt @ Help.DrnJdJJD.js:147 await in Nt Kt @ Help.DrnJdJJD.js:47 +layout.svelte:82 usage {models: Array(1)} +layout.svelte:82 usage {models: Array(1)} +layout.svelte:82 usage {models: Array(0)} ``` **Docker Container Logs:** - **Screenshots/Screen Recordings (if applicable):** ![image](https://github.com/user-attachments/assets/a5866fb0-97e5-49d5-8f00-a88c07915111) ## Additional Information 1. In my opinion, location access should be set locally in localStorage instead of being synced between all sessions. This way a user can have location access enabled on some devices and disabled on others. 2. If location variables are not used in slash prompts or system prompts location access shuldn't be checked by Open WebUI since it won't be used during the conversation.
GiteaMirror commented 2025-11-11 15:02:02 -06:00
Author
Owner
Copy Link

@tjbck commented on GitHub (Sep 24, 2024):

Agreed, feel free to make a PR!

@tjbck commented on GitHub (Sep 24, 2024): Agreed, feel free to make a PR!
GiteaMirror commented 2025-11-11 15:02:02 -06:00
Author
Owner
Copy Link

@sebdanielsson commented on GitHub (Sep 29, 2024):

Agreed, feel free to make a PR!

Feel free to assign the issue to me, and I'll fix it when I have time!😊

@sebdanielsson commented on GitHub (Sep 29, 2024): > Agreed, feel free to make a PR! Feel free to assign the issue to me, and I'll fix it when I have time!😊
GiteaMirror commented 2025-11-11 15:02:02 -06:00
Author
Owner
Copy Link

@silentoplayz commented on GitHub (Nov 16, 2024):

Any updates on this? Should this issue be closed or is there any desire to fix this if necessary still?

@silentoplayz commented on GitHub (Nov 16, 2024): Any updates on this? Should this issue be closed or is there any desire to fix this if necessary still?
GiteaMirror commented 2025-11-11 15:02:03 -06:00
Author
Owner
Copy Link

@sebdanielsson commented on GitHub (Nov 16, 2024):

Haven't had time to create a fix yet, but it's still on my todo list.

@sebdanielsson commented on GitHub (Nov 16, 2024): Haven't had time to create a fix yet, but it's still on my todo list.
GiteaMirror commented 2025-11-11 15:02:03 -06:00
Author
Owner
Copy Link

@DmitriyAlergant commented on GitHub (Nov 28, 2024):

Respectfully disagree that a config option somehow needs not to be synced. That breaks the entire consistency of user config being in one place. There is no need in that.

What I would do instead:

  1. Don't request browser location simply based on the setting if it was not requested in the prompt in the first place

  2. If location was requested but not obtained, quietly replace the placeholder with {unknown} location rather then failing the chat entirely.

@DmitriyAlergant commented on GitHub (Nov 28, 2024): Respectfully disagree that a config option somehow needs not to be synced. That breaks the entire consistency of user config being in one place. There is no need in that. What I would do instead: 1) Don't request browser location simply based on the setting if it was not requested in the prompt in the first place 2) If location was requested but not obtained, quietly replace the placeholder with {unknown} location rather then failing the chat entirely.
GiteaMirror commented 2025-11-11 15:02:03 -06:00
Author
Owner
Copy Link

@sebdanielsson commented on GitHub (Dec 17, 2024):

Respectfully disagree that a config option somehow needs not to be synced. That breaks the entire consistency of user config being in one place. There is no need in that.

What I would do instead:

  1. Don't request browser location simply based on the setting if it was not requested in the prompt in the first place
  2. If location was requested but not obtained, quietly replace the placeholder with {unknown} location rather then failing the chat entirely.

Agree and disagree. I agree that all options should be synced. However, there is no reason for location access to be a user option inside open-webui. The browser should only ask for location access if a prompt requires it. The option is already made at the browser level. If a user doesn't want open-webui to access their location, they can simply decline the popup requesting access. If the user does want to share location access, it should just be provided to the prompt.

What are your thoughts on this? @tjbck

@sebdanielsson commented on GitHub (Dec 17, 2024): > Respectfully disagree that a config option somehow needs not to be synced. That breaks the entire consistency of user config being in one place. There is no need in that. > > What I would do instead: > > 1. Don't request browser location simply based on the setting if it was not requested in the prompt in the first place > 2. If location was requested but not obtained, quietly replace the placeholder with {unknown} location rather then failing the chat entirely. Agree and disagree. I agree that all options should be synced. However, there is no reason for location access to be a user option inside open-webui. The browser should only ask for location access if a prompt requires it. The option is already made at the browser level. If a user doesn't want open-webui to access their location, they can simply decline the popup requesting access. If the user does want to share location access, it should just be provided to the prompt. What are your thoughts on this? @tjbck
GiteaMirror commented 2025-11-11 15:02:03 -06:00
Author
Owner
Copy Link

@DmitriyAlergant commented on GitHub (Dec 17, 2024):

.. However, there is no reason for location access to be a user option inside open-webui. The browser should only ask for location access if a prompt requires it. The option is already made at the browser level.

For one, this is already the case. It is already only requesting location (setting-permitting) if the prompt requires it. My prompts do not, and browsers are not asking for a location.

Secondly, browser-level permit is typically given once and then the browsers make hard to to track its status. While the prompt may have given or removed the location part over time. You may have given it once and then forgot. Or what's worse, for Safari, you can reject ("Decline for today") but it will keep buzzing you with a new request every day, etc.

So I think

  • The setting is justified to exist
  • The setting should be reworded as 'Send user location (when a prompt includes a location tag)" to avoid confusion
  • The settings should be stored server-side per user, not per-device
@DmitriyAlergant commented on GitHub (Dec 17, 2024): > .. However, there is no reason for location access to be a user option inside open-webui. The browser should only ask for location access if a prompt requires it. The option is already made at the browser level. For one, this is already the case. It is already only requesting location (setting-permitting) if the prompt requires it. My prompts do not, and browsers are not asking for a location. Secondly, browser-level permit is typically given once and then the browsers make hard to to track its status. While the prompt may have given or removed the location part over time. You may have given it once and then forgot. Or what's worse, for Safari, you can reject ("Decline for today") but it will keep buzzing you with a new request every day, etc. So I think - The setting is justified to exist - The setting should be reworded as 'Send user location (when a prompt includes a location tag)" to avoid confusion - The settings should be stored server-side per user, not per-device
GiteaMirror commented 2025-11-11 15:02:04 -06:00
Author
Owner
Copy Link

@sebdanielsson commented on GitHub (Dec 17, 2024):

.. However, there is no reason for location access to be a user option inside open-webui. The browser should only ask for location access if a prompt requires it. The option is already made at the browser level.

For one, this is already the case. It is already only requesting location (setting-permitting) if the prompt requires it. My prompts do not, and browsers are not asking for a location.

Secondly, browser-level permit is typically given once and then the browsers make hard to to track its status. While the prompt may have given or removed the location part over time. You may have given it once and then forgot. Or what's worse, for Safari, you can reject ("Decline for today") but it will keep buzzing you with a new request every day, etc.

So I think

  • The setting is justified to exist
  • The setting should be reworded as 'Send user location (when a prompt includes a location tag)" to avoid confusion
  • The settings should be stored server-side per user, not per-device

I really don't see the problem here.

First of all, the browser's per-site settings page for controlling location access is two clicks away (Chrome, Edge, Safari, Brave etc); it's not hard to track the current setting. Second, it makes sense for Safari to ask the user for access each time a prompt using location access is sent. If the user doesn't want to share location access, they shouldn't have the variable in the prompt. Third, I haven't seen a solution to the issue described on the first page. How would you solve this issue? The current behavior doesn't make sense.

@sebdanielsson commented on GitHub (Dec 17, 2024): > > .. However, there is no reason for location access to be a user option inside open-webui. The browser should only ask for location access if a prompt requires it. The option is already made at the browser level. > > For one, this is already the case. It is already only requesting location (setting-permitting) if the prompt requires it. My prompts do not, and browsers are not asking for a location. > > Secondly, browser-level permit is typically given once and then the browsers make hard to to track its status. While the prompt may have given or removed the location part over time. You may have given it once and then forgot. Or what's worse, for Safari, you can reject ("Decline for today") but it will keep buzzing you with a new request every day, etc. > > So I think > > * The setting is justified to exist > * The setting should be reworded as 'Send user location (when a prompt includes a location tag)" to avoid confusion > * The settings should be stored server-side per user, not per-device I really don't see the problem here. First of all, the browser's per-site settings page for controlling location access is two clicks away (Chrome, Edge, Safari, Brave etc); it's not hard to track the current setting. Second, it makes sense for Safari to ask the user for access each time a prompt using location access is sent. If the user doesn't want to share location access, they shouldn't have the variable in the prompt. Third, I haven't seen a solution to the issue described on the first page. How would you solve this issue? The current behavior doesn't make sense.
GiteaMirror commented 2025-11-11 15:02:04 -06:00
Author
Owner
Copy Link

@1e100 commented on GitHub (Feb 14, 2025):

Seems like as of the most recent release "allow user location" is actually "require user location" in practice. "Allow" to me means that it'll attempt to get user location via the browser API, but if that fails, things would still function. Currently they do not - if I deny location access, the request can't proceed at all.

@1e100 commented on GitHub (Feb 14, 2025): Seems like as of the most recent release "allow user location" is actually "require user location" in practice. "Allow" to me means that it'll attempt to get user location via the browser API, but if that fails, things would still function. Currently they do not - if I deny location access, the request can't proceed at all.
GiteaMirror commented 2025-11-11 15:02:04 -06:00
Author
Owner
Copy Link

@sebdanielsson commented on GitHub (Feb 23, 2025):

With #10634 I've updated the behavior to set the location to LOCATION_UNKNOWN if location access is not permitted.

@sebdanielsson commented on GitHub (Feb 23, 2025): With #10634 I've updated the behavior to set the location to LOCATION_UNKNOWN if location access is not permitted.
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
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#2190
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?