Bugzilla

The central piece of the code that's relevant to this is probably `ScrollFrameHelper::GetScrolledRect`, particularly near the end where it branches on `GetScrolledFrameDir()` to handle scroll ranges for right-to-left (RTL) direction pages (e.g., Arabic, Hebrew).

However, there are likely a bunch of interesting side-effects of changing that, such as:
* we need to make sure the various scrolling-related APIs are compatible with other implementations (e.g., `Element::scrollTo`, `Element.scrollTop`, `Element.scrollLeft`) in terms of what point is considered `0` (that is, is it the left/top edge or is it the initial position?).  (We might have incompatibility with other browsers for the RTL case here today.)
* there might be some pieces of code that make assumptions about not scrolling above the initial position, or the initial scroll position being 0, or the vertical scroll position never being negative

The underlying design question around a bunch of these differences is that it's not clear whether to model this as the initial scroll position being `0` and the rest of the range being negative (which I believe is how we model it for RTL in Gecko), or whether to model it as the scroll range all being positive positions but the initial scroll position being nonzero.  So it's worth looking into what other browsers expose both for the flex case and for the RTL case.

The central piece of the code that's relevant to this is probably [`ScrollFrameHelper::GetScrolledRect`](https://searchfox.org/mozilla-central/search?q=symbol:_ZNK7mozilla17ScrollFrameHelper15GetScrolledRectEv&redirect=false), particularly near the end where it branches on `GetScrolledFrameDir()` to handle scroll ranges for right-to-left (RTL) direction pages (e.g., Arabic, Hebrew).

However, there are likely a bunch of interesting side-effects of changing that, such as:
* we need to make sure the various scrolling-related APIs are compatible with other implementations (e.g., `Element::scrollTo`, `Element.scrollTop`, `Element.scrollLeft`) in terms of what point is considered `0` (that is, is it the left/top edge or is it the initial position?).  (We might have incompatibility with other browsers for the RTL case here today.)
* there might be some pieces of code that make assumptions about not scrolling above the initial position, or the initial scroll position being 0, or the vertical scroll position never being negative

The underlying design question around a bunch of these differences is that it's not clear whether to model this as the initial scroll position being `0` and the rest of the range being negative (which I believe is how we model it for RTL in Gecko), or whether to model it as the scroll range all being positive positions but the initial scroll position being nonzero.  So it's worth looking into what other browsers expose both for the flex case and for the RTL case.