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

[GH-ISSUE #22744] issue: Secondary Hover Menus (e.g., Download/Move in Chat Menu) Disappear Before Selection #58472

New Issue
Closed
opened 2026-05-05 23:13:50 -05:00 by GiteaMirror · 4 comments
GiteaMirror commented 2026-05-05 23:13:50 -05:00
Owner
Copy Link

Originally created by @silentoplayz on GitHub (Mar 17, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/22744

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

v0.8.10

Ollama Version (if applicable)

v0.18.0

Operating System

Ubuntu 24.04.4 LTS

Browser (if applicable)

Mozilla Firefox Snap for Ubuntu v148.0.2 (64-bit) / Google Chrome v146.0.7680.80 (Official Build) (64-bit)

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 hovering over the Download or Move options from a chat's 3-dot (hamburger) menu in the sidebar, the secondary sub-menu should remain open and accessible long enough for the user to move their cursor into it and make a selection.

Actual Behavior

The secondary DropdownSub menu frequently disappears the moment the user attempts to move their mouse from the primary menu item (e.g., Download) into the rendered sub-menu. It is extremely difficult to catch the menu in time before the mouseleave event fires and destroys the component.

Steps to Reproduce

  1. Start an Open WebUI instance utilizing the v0.8.10 version on Ubuntu 24.04.4 LTS using Firefox v148.0.2.
  2. Locate any existing chat in your left sidebar.
  3. Click the 3-dot (hamburger) menu icon next to the chat name to open the primary dropdown menu.
  4. Move your cursor to hover over the Download option. A secondary sub-menu will appear to the side.
  5. Attempt to move your mouse cursor from the word Download into the new sub-menu to click Plain text (.txt).
  6. Observe that the sub-menu instantly vanishes before your mouse can reach it.

Logs & Screenshots

https://github.com/user-attachments/assets/c09880a8-937e-4b73-bafd-3e712a5c334d

Additional Information

The bug may have been introduced by styling changes in rc/lib/components/common/DropdownSub.svelte. The sideOffset property defaults to 8 pixels. Because the sub-menu is physically separated from the trigger element by an 8px dead zone, moving the mouse across this gap triggers the mouseleave event on the trigger element before the mouseenter event can fire on the sub-menu content.

This can be fixed by implementing one of the following solutions:

  1. Setting sideOffset = 0 (or a negative margin) so the elements physically overlap, maintaining a continuous hover state.
  2. Adding an invisible padding/border bridge via CSS to span the 8px gap so the mouse never technically "leaves" the interactive area.
  3. Adding a small debounce timeout (setTimeout) to the handleMouseLeave function in DropdownSub.svelte to give the user 100-200ms to cross the gap before the menu open state is forced to false.
Originally created by @silentoplayz on GitHub (Mar 17, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/22744 ### 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 v0.8.10 ### Ollama Version (if applicable) v0.18.0 ### Operating System Ubuntu 24.04.4 LTS ### Browser (if applicable) Mozilla Firefox Snap for Ubuntu v148.0.2 (64-bit) / Google Chrome v146.0.7680.80 (Official Build) (64-bit) ### 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 hovering over the `Download` or `Move` options from a chat's 3-dot (hamburger) menu in the sidebar, the secondary sub-menu should remain open and accessible long enough for the user to move their cursor into it and make a selection. ### Actual Behavior The secondary `DropdownSub` menu frequently disappears the moment the user attempts to move their mouse from the primary menu item (e.g., `Download`) into the rendered sub-menu. It is extremely difficult to catch the menu in time before the `mouseleave` event fires and destroys the component. ### Steps to Reproduce 1. Start an Open WebUI instance utilizing the `v0.8.10` version on Ubuntu 24.04.4 LTS using Firefox v148.0.2. 2. Locate any existing chat in your left sidebar. 3. Click the 3-dot (hamburger) menu icon next to the chat name to open the primary dropdown menu. 4. Move your cursor to hover over the `Download` option. A secondary sub-menu will appear to the side. 5. Attempt to move your mouse cursor from the word `Download` into the new sub-menu to click `Plain text (.txt)`. 6. Observe that the sub-menu instantly vanishes before your mouse can reach it. ### Logs & Screenshots https://github.com/user-attachments/assets/c09880a8-937e-4b73-bafd-3e712a5c334d ### Additional Information The bug may have been introduced by styling changes in `rc/lib/components/common/DropdownSub.svelte`. The `sideOffset` property defaults to `8` pixels. Because the sub-menu is physically separated from the trigger element by an 8px dead zone, moving the mouse across this gap triggers the `mouseleave` event on the trigger element *before* the `mouseenter` event can fire on the sub-menu content. This can be fixed by implementing one of the following solutions: 1. Setting `sideOffset = 0` (or a negative margin) so the elements physically overlap, maintaining a continuous hover state. 2. Adding an invisible padding/border bridge via CSS to span the 8px gap so the mouse never technically "leaves" the interactive area. 3. Adding a small debounce timeout (`setTimeout`) to the `handleMouseLeave` function in [DropdownSub.svelte](file:///home/g30/docker-projects/open-webui-dev/src/lib/components/common/DropdownSub.svelte) to give the user 100-200ms to cross the gap before the menu `open` state is forced to `false`.
GiteaMirror added the bugconfirmed issue labels 2026-05-05 23:13:51 -05:00
GiteaMirror commented 2026-05-05 23:13:56 -05:00
Author
Owner
Copy Link

@silentoplayz commented on GitHub (Mar 17, 2026):

This issue is more widespread than simply the chat's Download and Move options in a chat's 3-dots (hamburger) menu icon.

I've also traced the issue to the 3-dots (hamburger) menu icon for any note found in the Notes section of the Workspace.

Image

And also with the 3-dots (hamburger) menu icon found on the Chats page in the Playground section.

Image
<!-- gh-comment-id:4072711937 --> @silentoplayz commented on GitHub (Mar 17, 2026): This issue is more widespread than simply the chat's `Download` and `Move` options in a chat's 3-dots (hamburger) menu icon. I've also traced the issue to the 3-dots (hamburger) menu icon for any note found in the `Notes` section of the `Workspace`. <img width="422" height="168" alt="Image" src="https://github.com/user-attachments/assets/0a1226b1-1887-483b-afb9-da96f54bc2b9" /> And also with the 3-dots (hamburger) menu icon found on the `Chats` page in the `Playground` section. <img width="440" height="158" alt="Image" src="https://github.com/user-attachments/assets/45c8ca86-3d06-4ef5-9ba8-a4e8bcc8e382" />
GiteaMirror commented 2026-05-05 23:14:01 -05:00
Author
Owner
Copy Link

@majiayu000 commented on GitHub (Mar 21, 2026):

Hi, I've been looking into this and traced the root cause.

Proposed approach: Fix DropdownSub.svelte by adding a CSS invisible bridge (pseudo-element or padding) to span the 8px sideOffset gap, preventing mouseleave from firing during cursor transit. This is the cleanest approach — it preserves the visual gap while maintaining hover continuity. Alternative: add a ~150ms debounce to handleMouseLeave. The CSS bridge is preferred as it's zero-JS and handles all cursor speeds. Test across all affected locations (chat sidebar, Notes workspace, Playground Chats).

I'll open a draft PR shortly. Happy to adjust based on your preference.

<!-- gh-comment-id:4101834933 --> @majiayu000 commented on GitHub (Mar 21, 2026): Hi, I've been looking into this and traced the root cause. **Proposed approach:** Fix DropdownSub.svelte by adding a CSS invisible bridge (pseudo-element or padding) to span the 8px sideOffset gap, preventing mouseleave from firing during cursor transit. This is the cleanest approach — it preserves the visual gap while maintaining hover continuity. Alternative: add a ~150ms debounce to handleMouseLeave. The CSS bridge is preferred as it's zero-JS and handles all cursor speeds. Test across all affected locations (chat sidebar, Notes workspace, Playground Chats). I'll open a draft PR shortly. Happy to adjust based on your preference.
GiteaMirror commented 2026-05-05 23:14:08 -05:00
Author
Owner
Copy Link

@tjbck commented on GitHub (Mar 24, 2026):

Should be addressed.

<!-- gh-comment-id:4121747259 --> @tjbck commented on GitHub (Mar 24, 2026): Should be addressed.
GiteaMirror commented 2026-05-05 23:14:11 -05:00
Author
Owner
Copy Link

@silentoplayz commented on GitHub (Mar 24, 2026):

Should be addressed.

I can confirm the reported issue has been resolved on the dev branch. Thanks!

<!-- gh-comment-id:4122073023 --> @silentoplayz commented on GitHub (Mar 24, 2026): > Should be addressed. I can confirm the reported issue has been resolved on the `dev` branch. Thanks!
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 confirmed issue
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#58472
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?