[Affected versions]:

• Latest Nightly 66.0a1
• beta 65.0b9
• Firefox 64.0.2

[Affected platforms]:

• macOS 10.14

[Steps to reproduce]:

1. Go to https://www.twitch.tv/videos/360698521.
2. In the chat try to hover over the edit button on one of the comments (the three vertical buttons).

[Expected result]:

• The button can be easily clicked.

[Actual result]:

• The scrollbar covers the button.

[Regression range]:

• I don't know if it's a regression, but I will try to find as soon as possible.

[Additional notes]:

• Please look at the attached gif.
• I can reproduce the issue only on macOS 10.14.
• The issue is reproducing even if the browser is in fullscreen mode.
• The issue is reproducing only on the chats for the videos that are not live.

Does this always happen regardless of which comments are in view? Or, does it only happen when there's a particularly-wide comment, perhaps?

I just tried to reproduce on Mac OS Mojave with Firefox 64 (remotely via BrowserStack, since I'm not running Mac locally), and I wasn't able to reproduce. The menu was nicely positioned to the left of the scrollbar area, for me.

(i.e. this sounds possibly related to bug 1468066)

It doesn't matter how long the comment is. It's related more to the scroll. Because if you scroll through the comments then the scrollbar doesn't disappear that fast and if you are trying to to access the menu, the scrollbar is sliding underneath the cursor.
I am not sure what is the difference. I used a MacBook Pro (13-inch,2017, Four Thunderbolt 3 Ports)and macOS Mojave 10.14.3.

OK - I was confused because it turns out my BrowserStack remote mac machine was configured to show scrollbars all the time (not overlay scrollbars).

On a mac of my own, with overlay scrollbars, I do see the issue you describe. Chrome and Safari are unaffected, because they show a scrollbar all the time despite the OS settings to show overlay scrollbars.

It looks like this is because Twitch is signalling that they do want a permanent scrollbar of a specific size here, via this styling:

.video-chat__message-list-wrapper::-webkit-scrollbar {
    width: .6rem;
}

https://static.twitchcdn.net/assets/pages.channel.components.channel-root-31bd952b4ce33282d2e8.css

So this is dependent on bug 1432935.

Hmmm, so we don't have a property to force the scrollbar to show up all the time.

Daniel, could you try if setting

.video-chat__message-list-wrapper {
    scrollbar-width: thin;
}

makes it better?

scrollbar-width: none would certainly fix this but it also completely hide the scrollbar which may not be desirable either.

(In reply to Xidorn Quan [:xidorn] UTC+11 from comment #5)

Hmmm, so we don't have a property to force the scrollbar to show up all the time.

Darn. That seems to be what they want/need here, in order to reliably draw a button at the far-right edge of a scrollable area and to have that button be clickable.

Daniel, could you try if setting [...]scrollbar-width: thin;[...] makes it better?

A little bit better, maybe, but not much better. The scroll track is still thick enough to cover up these buttons.

When I hover the scrollbar area (e.g. maybe because I'm trying to click one of the "..." buttons on the right edge of a comment and I overshoot slightly), then the scroll track appears and covers up the button. (And if I compare 'scrollbar-width:[initial/unspecified]' to 'scrollbar-width:thin', the scroll track only gets slightly thinner -- e.g. compare 0:04 default-thickness to 0:14 "thin" thickness, in my screencast.)

scrollbar-width: none would certainly fix this but it also completely hide the scrollbar which may not be desirable either.

Yeah, that does kinda-work (it makes the scrollbar never show up), but that seems to be the opposite of twitch wants (always-show-up).

Concrete example of 'thin' not being better: Right around 0:14-15 and 0:18-19 in my screencast, you can see one of the "..." buttons being covered up by the scroll track, even with scrollbar-width:thin.

Hmmm, this is probably a case which we didn't take into account.

I guess standard-wise, one solution is to expose something similar to our -moz-overlay-scrollbar media query, and have an explicit padding when that matches. Another is to have a property to disable overlay scrollbar...

As discussed with Mike, we'll address this issue as part of a Proof-of-Concept WebCompat intervention. Because setting the scrollbar to thin isn't enough, the proposed intervention hides it entirely. Attaching the Pull Request for reference, and to create a paper trail to that work.

The intervention for that is shipping in 68, as the code was synced in bug 1536767. Closing as Fixed.