STR: (1) View https://bugzilla.mozilla.org/attachment.cgi?id=9213617 (2) Look at the scrollbars inside the two black boxes. (you may have to manually scroll them to make the scrollbars show up, if you've got overlay scrollbars.) EXPECTED RESULTS: The scrollbar should be on the same side of the two black boxes. (Both of these boxes have "right-to-left" content flows, via `direction:rtl` for the first one and via `vertical-rl` for the second one.) In particular: I think the scrollbar should be on the **left side** for both boxes. (In both cases, the left side is the logical "end" side -- it's the inline-end edge of the the first box, and it's the block-end side for the second box.). ACTUAL RESULTS: Safari/WebKit places the scrollbar on the **right side** of the second box (the `vertical-rl` one). This is the logical "start" side (specifically "block-start"), which is an odd place for a scrollbar. I think this is the only case where Safari does this (where they place the scrollbar on a "start" side of a box). Firefox gives EXPECTED RESULTS here. Chrome matches Safari and gives ACTUAL RESULTS, but that's a Chrome bug, and it sounds like they're likely changing to match Firefox on this, per https://bugs.chromium.org/p/chromium/issues/detail?id=1195933#c6 . (That's the Chrome version of this issue.) I tested this in Safari 14 on macOS Big Sur.
Note that there's a WPT test that inadvertently depends on this behavior (and fails in Firefox as a result), which is how I ran across cross-browser discrepancy: https://wpt.fyi/results/css/css-flexbox/overflow-auto-005.html I may end up fixing that WPT test over in https://bugzilla.mozilla.org/show_bug.cgi?id=1703074 , and/or it might get fixed as part of the bug report. Either way, it'll likely end up flipping its implicit expectation about scrollbar placement (which isn't really what it's intending to test anyway). (unless there's a case to be made that both behaviors are sensible, and if the text can be relaxed such that it allows both somehow)
(In reply to Daniel Holbert from comment #1) > unless there's a case to be made that both > behaviors are sensible, and if the text can be relaxed such that it allows > both somehow) Sorry, s/text/test/
Seems like a bug, yeah.
I can reproduce this on Safari 13.1.2 as well as TOT 14.2.
<rdar://problem/76366184>
Created attachment 425482 [details] Patch
Created attachment 425568 [details] Patch
(In reply to Daniel Holbert from comment #1) > Note that there's a WPT test that inadvertently depends on this behavior > (and fails in Firefox as a result), which is how I ran across cross-browser > discrepancy: > https://wpt.fyi/results/css/css-flexbox/overflow-auto-005.html > > I may end up fixing that WPT test over in > https://bugzilla.mozilla.org/show_bug.cgi?id=1703074 , and/or it might get > fixed as part of the bug report. Either way, it'll likely end up flipping > its implicit expectation about scrollbar placement (which isn't really what > it's intending to test anyway). (unless there's a case to be made that both > behaviors are sensible, and if the text can be relaxed such that it allows > both somehow) Hey Daniel, do you think css/css-writing-modes/sizing-orthog-vrl-in-htb-012.xht also needs fixing? That's a case where the reference is using `writing-mode: vertical-rl` on the root, while the test itself has the default horizontal-tb. But scrollbar position is not what's being tested.
css/cssom-view/cssom-getBoundingClientRect-vertical-rl.html too.
Created attachment 425584 [details] Patch
r?dholbert https://github.com/web-platform-tests/wpt/pull/28425
Yeah, that seems fine (marked r+ in WPT repo). It surprises me that Firefox places the scrollbars on the right side in those tests (I checked, and we do). It seems the root scrollport is special for some reason; I'm not sure if that's intentional or not. But yeah, in any case, scrollbar-side-placement isn't what those testcases are trying to test.
I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1704122 on the fact that Firefox seems to have special right-side-scrollbars-only behavior on the root element.
Created attachment 425694 [details] Squashed patch with dependencies for EWS
Created attachment 425831 [details] Squashed patch with dependencies for EWS
Created attachment 425835 [details] Squashed patch with dependencies for EWS
Created attachment 425839 [details] Squashed patch with dependencies for EWS
Created attachment 425931 [details] Patch
Created attachment 425934 [details] Patch
Created attachment 425953 [details] Patch
Created attachment 426087 [details] Patch
Created attachment 426137 [details] Patch
Created attachment 426168 [details] Patch
Committed r276182 (236665@main): <https://commits.webkit.org/236665@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 426168 [details].
Reopening to attach new patch.
Created attachment 426296 [details] Patch
Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See https://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API
Sorry, not sure why `webkit-patch` uploaded to this bug. Closing again.