[GH-ISSUE #13771] issue: Scroll wheel doesn't scroll the page when hovering the buttons container element #17024

New Issue

GiteaMirror · 2026-04-19T22:48:29-05:00

GiteaMirror commented

2026-04-19 22:48:29 -05:00

Originally created by @rotemdan on GitHub (May 11, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/13771

Check Existing Issues

I have searched the existing issues and discussions.
I am using the latest version of Open WebUI.

Installation Method

Docker

Open WebUI Version

v0.6.9

Ollama Version (if applicable)

No response

Operating System

Windows 11

Browser (if applicable)

Brave v1.78.97

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 listed steps to reproduce the bug in detail.

Expected Behavior

Page scrolls using the mouse scroll wheel when cursor is positioned anywhere within the messages window.

Actual Behavior

Page doesn't scroll with scroll the mouse scroll wheel when over the button container div element.

Steps to Reproduce

Position the mouse over the buttons container element
Try to scroll using the mouse wheel

Logs & Screenshots

The buttons container div element is highlighted in blue, in this image:

Additional Information

The behavior was introduced by this commit, which prevents default scroll events over the container, and instead routes them to horizontally scrolling the button container element, even when it doesn't overflow horizontally.

In src/lib/components/chat/Messages/ResponseMessage.svelte, changing to:

	onMount(async () => {
		// console.log('ResponseMessage mounted');

		await tick();
		if (buttonsContainerElement) {
			console.log(buttonsContainerElement);
			buttonsContainerElement.addEventListener('wheel', function (event) {
				// console.log(event.deltaY);

				// Check if the buttons container element has horizontal overflow,
				// and reroute the scroll wheel to scroll it horizontally, in that case.
				if (buttonsContainerElement.scrollWidth > buttonsContainerElement.clientWidth) {
					event.preventDefault();
					if (event.deltaY !== 0) {
						// Adjust horizontal scroll position based on vertical scroll
						buttonsContainerElement.scrollLeft += event.deltaY;
					}
				}
			});
		}
	});

Should resolve the issue, by only routing the scroll wheel to horizontal scrolling when the element overflows, and otherwise allowing normal scrolling of the page.

I can give a pull request, but I wanted to report the issue first. Let me know if you want a pull request for this, or prefer a different approach.

Originally created by @rotemdan on GitHub (May 11, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/13771 ### Check Existing Issues - [x] I have searched the existing issues and discussions. - [x] I am using the latest version of Open WebUI. ### Installation Method Docker ### Open WebUI Version v0.6.9 ### Ollama Version (if applicable) _No response_ ### Operating System Windows 11 ### Browser (if applicable) Brave v1.78.97 ### 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 listed steps to reproduce the bug in detail. ### Expected Behavior Page scrolls using the mouse scroll wheel when cursor is positioned anywhere within the messages window. ### Actual Behavior Page doesn't scroll with scroll the mouse scroll wheel when over the button container `div` element. ### Steps to Reproduce 1. Position the mouse over the buttons container element 2. Try to scroll using the mouse wheel ### Logs & Screenshots The buttons container `div` element is highlighted in blue, in this image: ![Image](https://github.com/user-attachments/assets/3b9ca6a5-a157-450d-90de-bd35d22419c0) ### Additional Information The behavior was introduced by [this commit](https://github.com/open-webui/open-webui/commit/737b1723c7edb5b85140a23dfa28c5b5ff7aef48), which prevents default scroll events over the container, and instead routes them to horizontally scrolling the button container element, even when it doesn't overflow horizontally. In [`src/lib/components/chat/Messages/ResponseMessage.svelte`](https://github.com/open-webui/open-webui/blob/0cef844168e97b70de2abee4c076cc30ffec6193/src/lib/components/chat/Messages/ResponseMessage.svelte#L566), changing to: ```ts onMount(async () => { // console.log('ResponseMessage mounted'); await tick(); if (buttonsContainerElement) { console.log(buttonsContainerElement); buttonsContainerElement.addEventListener('wheel', function (event) { // console.log(event.deltaY); // Check if the buttons container element has horizontal overflow, // and reroute the scroll wheel to scroll it horizontally, in that case. if (buttonsContainerElement.scrollWidth > buttonsContainerElement.clientWidth) { event.preventDefault(); if (event.deltaY !== 0) { // Adjust horizontal scroll position based on vertical scroll buttonsContainerElement.scrollLeft += event.deltaY; } } }); } }); ``` Should resolve the issue, by only routing the scroll wheel to horizontal scrolling when the element overflows, and otherwise allowing normal scrolling of the page. I can give a pull request, but I wanted to report the issue first. Let me know if you want a pull request for this, or prefer a different approach.

GiteaMirror added the bug label 2026-04-19 22:48:29 -05:00

GiteaMirror closed this issue

2026-04-19 22:48:30 -05:00

GiteaMirror commented

2026-04-19 22:48:31 -05:00

@tjbck commented on GitHub (May 14, 2025):

Addressed with 7e241a3904

@tjbck commented on GitHub (May 14, 2025): Addressed with 7e241a3904b0cdc50d8f85eed486280c76c62267

GiteaMirror referenced this issue

2026-04-20 00:17:07 -05:00

[GH-ISSUE #17024] issue: Document embedding = uploading documents to the chat sometimes doesn't work - active: hybrid search/reranker in v.0.6.26 [update] and in v.0.6.25 #18141

GiteaMirror referenced this issue