The scrollbar of the chat conversations list uses some RTL/LTR hack to appear on the opposite side it would normally be. However, the scrollbar is now being drawn over top the spaces toolbar, or not at all if the spaces toolbar is hidden. I assume this is only an issue on GTK and none of the other toolkits, so I marked this as a Linux bug. Maybe there is a way to force the old "permanent" scrollbar style, instead of the new disappearing scrollbar style?

Regression range: https://hg.mozilla.org/comm-central/pushloghtml?fromchange=6f8d813011d393a68cf809daca344478984e7aac&tochange=73a117e64bdafffa172dadb4cff12ed2254d9917 - I assume that means this is an m-c change to scrollbar rendering that caused it.

Looking at the m-c pushlog for that timerange, likely bug 1147847

Does the contact listbox stay like it is now or is a redesign planned that makes the forcing the move of the scrollbar to the left obsolete?

If not, we should ask Emilio if this is a M-C bug or what we can do to fix this.

Gently pinging Emilio to see if he has any insights on this.

We will remove that richlistbox element after 102, so for now a very temporary band-aid fix would be more than enough.

I guess with the disappearing scrollbars we could arguably move the scrollbar back to its normal location? Though I guess they're not enabled on release currently?

On Windows 10 the scrollbar isn't disappearing and not a overlay scrollbox. But it is also correctly inside the contacts box.

So in terms of restoring pre-existing behavior, setting widget.gtk.overlay-scrollbars.enabled=false should work. However I'd expect this to be an issue on macOS (when having overlay scrollbars) as well, is it not?

Indeed, this happens also on macos.
With the additional super wonderful bleeding out of the whole list above the toolbar.

Yeah so thus would be an issue as well on Windows 11. Some scrollbars code is confused about which side to pull the scrollbars from. I'm not super sure bug 1764435 is related but does setting layout.css.cached-scrollbar-styles.enabled=false help (after a restart?)

(In reply to Emilio Cobos Álvarez (:emilio) from comment #6)

However I'd expect this to be an issue on macOS (when having overlay scrollbars) as well, is it not?

On Windows 11 too.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #8)

Yeah so thus would be an issue as well on Windows 11. Some scrollbars code is confused about which side to pull the scrollbars from. I'm not super sure bug 1764435 is related but does setting layout.css.cached-scrollbar-styles.enabled=false help (after a restart?)

On Windows 11 there is no change. The scrollbar is still outside of the box.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #8)

Yeah so thus would be an issue as well on Windows 11. Some scrollbars code is confused about which side to pull the scrollbars from. I'm not super sure bug 1764435 is related but does setting layout.css.cached-scrollbar-styles.enabled=false help (after a restart?)

That moves the scrollbar even further to the left, instead of being just adjacent it now has an entire scrollbar wide gap.

Something not noted in my initial report is that it doesn't transform into the "full" scrollbar on hover and instead stays in its thin form.

This is no longer an issue for me in 102.

mozregression says it was fixed by https://hg.mozilla.org/comm-central/pushloghtml?fromchange=deb7fbdd072298ff73b52000a4241b62c9077230&tochange=f683edfb14c7de6f5421999da3a65c7241555381 which I think means it was likely fixed by Bug 1771211