User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:100.0) Gecko/20100101 Firefox/100.0

Steps to reproduce:

Use firefox 100 and view a page with a scrollable element which has its direction set to RTL (right-to-left)

Actual results:

On a scrollable element with its direction set to RTL (right-to-left), the scroll bar appears on the left side of the element, but the scroll bar itself is aligned to the right of the region it occupies. The result is that the new scroll bars which are meant to be less obtrusive by getting out of the way when they are not being used are more obtrusive.

To summarize: on a scrollable element with its direction set to RTL, the scroll bar correctly appears on the left side of the element, but scroll bar handle is incorrectly aligned to the right, causing it to overlap more content than it should.

Expected results:

When a scrollable element has its direction let to LTR, its scroll bar should appear on the right and be aligned to the right. When a scrollable element has its direction set to RTL, its scroll bar should appear on the left and be aligned to the left.

I've put together an image to better communicate the problem: https://i.imgur.com/TOms5PH.png

I don't think it's intended that the gap between the scroll bar in its un-expanded state and the edge of the element is different when the element is RTL vs when the element is LTR.

I think we've had this bug with overlay scrollbars for a while, but 100 is the first release to get overlay scrollbars on Linux. You can temporarily disable them via the pref widget.gtk.overlay-scrollbars.enabled until this gets fixed. I'm guessing we're using the width of non-overlay scrollbars to move the overlay scrollbars? I can see the issue on mac too.

Hmm, no, we are giving both scrollbars on the right and the left the same rect but the scrollbar drawing code just uses the right part of the rect to draw into?

I think this is bug 1764435.