Scrollbar is not pressable at the right edge of the viewport

[rotemdan]

Bug description

When the the mouse is located at the right edge of the viewport, the scroll bar is not responsive to clicks (pressing the left mouse button would cause text selection instead, which is not expected behavior).

It requires slight positioning to the left to get it pressed.

This is an issue with many different websites, but I've found a simple way to solve it here.

Steps to reproduce

1. Position the mouse at the right edge of the viewport
2. Try to press and drag the scrollbar

Screen capture

Specs

• OS: Windows 11
• Browser: Brave Version 1.70.117 Chromium: 129.0.6668.59 (Official Build) (64-bit)
• chat-ui commit: v0.9.2 (web)

Temporary fix using a custom stylesheet

1. Install the Stylus extension

2. Apply this stylesheet to https://huggingface.co/chat/

@-moz-document url-prefix("https://huggingface.co/chat/") {
    div.scrollbar-custom {
        margin-right: 0px !important;
    }
}

The stylesheet simply zeros the right margin for the element that includes the scrollbar. The margin is otherwise 4px, which causes the problem.

Screen capture after applying stylesheet

Thanks

I've been frustrated by this issue for a while now. I'm glad I've found a temporary workaround.

I would appreciate the issue being fixed for all users. Sometimes what looks like a minor UI fix can make a surprisingly large improvement in the overall user experience.

[nsarrazin]

Hi, thanks for reporting an issue! Looks like you already have a fix, if you want to open it as a PR i'll happily review it :rocket:

[rotemdan]

The workaround I gave basically overrides some CSS properties with a browser extension.

In order to fix this properly, it should modify the cause of why the margin is added in the first place.

The particular HTML class that adds the margin seems to be .mr-1:

It's added to the element:

There are 4 source files that include a div element with the combination of scrollbar-custom mr-1:

src/lib/components/chat/ChatWindow.svelte src/routes/assistants/+page.svelte src/routes/models/+page.svelte src/routes/tools/+page.svelte

I could just remove mr-1 from all of them but I'm not really familiar with what each does, and not sure how exactly they would be impacted by this.

I can't really make a pull request without being sure what I'm doing makes sense.

Edit: I did make a pull request with these changes, but didn't test it since I couldn't get chat-ui to run locally (issues with database, etc.)

[rotemdan]

I can see the fix has been applied to the web interface at https://huggingface.co/chat. Thanks.

[rotemdan]

Issue has now returned. I'm not sure exactly when, but I think even yesterday it still worked correctly.

Looking at the updated source code, the files, where I applied changes to remove the mr-1 classes from tags, have changed significantly.

I see the mr-1 and mr-1.5 class added in many different places. The code looks very different from when I made the changes previously.

Figuring out what changes to make to fix the issue was hard enough the last time. I don't know if I could go through it again. As a maintainer of many different open-source repositories myself, I'd never ask a user for a second pull request on an issue they correctly fixed earlier, if the reason it broke again is not related to them.

[nsarrazin]

Hi, I'll take a look :smile:

[nsarrazin]

pushed a fix for it, deploying now, should be live in 5-10min. thanks for the report!

[rotemdan]

The pull request I made was actually to remove the mr-1 class from multiple locations.

mr-1, I believe, means, a right margin of 1. By removing the right margin, the scrollbar became responsive at the edge, since it was "tucked" up to the very last rightmost pixel of the viewport. The recent change made was to add mr-1. I don't think that would have the right effect (that would be surprising, in any case).

In the new code I see mr-1 and mr-1.5 in many places. I don't know which of them impacts the margin next to a scrollbar. In other words, I don't know which to remove:

[rotemdan]

The change adds a margin of 4, increasing the gap to the right edge of the viewport:

The 4 pixel margin didn't exist before I reloaded the page. So even without a margin on the outer element, the scrollbar wasn't seen by the browser as being positioned at the right edge of the viewport.

Maybe the issue is now related to a margin added to an inner element, not necessarily the outer one. Browsers (testing on Chromium) can be sensitive to these margins, even to fractional pixels sometimes.

[rotemdan]

I spent an hour looking at diffs from the past few days and couldn't see any change that could impact this.

Now I understand the problem. Everything was actually fine with the website, it's just that Chromium has a persistent bug, (many years), that occurs at some zoom levels, and produces this behavior.

It turns out I accidentally changed the zoom level of my browser to 125% (where the issue occurs), causing me to perceive the issue as coming from the website, where in fact it was just the browser.

Reverting the margin of scrollbar-custom, the issue is not seen at zoom levels other than 125%. I knew about the Chromium bug for years, it's just that I didn't realize that was causing it at this particular time (maybe I should report it to Google, I don't know, I'll try?).

So just revert the recent change. Everything is alright. Sorry for any time spent on this.

[rotemdan]

Here is how the Chromium bug looks like, on different zoom levels (website is open-webui, not chat-ui). In the case of open-webui, it occurs at a 110% zoom level, but not on other zoom levels:

The chromium bug doesn't occur on all websites, for example, it doesn't happen on Mistral or ChatGPT. I can't quite isolate what minimal circumstances it takes to reproduce it, which makes it hard to submit a good issue on the Chromium tracker.

Edit: the chromium bug doesn't seem to be affected by the custom scrollbar, it happens even it's disabled. My guess it is some sort of fractional pixel sizing or some sort of rounding that is caused by the zoom level.