WebKit is inconsistent about which side to place scrollbar on (with writing-mode & direction CSS properties)

• Component: Layout and Rendering
• Status: RESOLVED FIXED

[Daniel Holbert]

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.

[Daniel Holbert]

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)

[Daniel Holbert]

(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/

[Simon Fraser (smfr)]

Seems like a bug, yeah.

[Smoley]

I can reproduce this on Safari 13.1.2 as well as TOT 14.2.

[Radar WebKit Bug Importer]

<rdar://problem/76366184>

[Cameron McCormack (:heycam)]

Created attachment 425482 [details]
Patch

[Cameron McCormack (:heycam)]

Created attachment 425568 [details]
Patch

[Cameron McCormack (:heycam)]

(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.

[Cameron McCormack (:heycam)]

css/cssom-view/cssom-getBoundingClientRect-vertical-rl.html too.

[Cameron McCormack (:heycam)]

Created attachment 425584 [details]
Patch

[Cameron McCormack (:heycam)]

r?dholbert https://github.com/web-platform-tests/wpt/pull/28425

[Daniel Holbert]

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.

[Daniel Holbert]

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.

[Cameron McCormack (:heycam)]

Created attachment 425694 [details]
Squashed patch with dependencies for EWS

[Cameron McCormack (:heycam)]

Created attachment 425831 [details]
Squashed patch with dependencies for EWS

[Cameron McCormack (:heycam)]

Created attachment 425835 [details]
Squashed patch with dependencies for EWS

[Cameron McCormack (:heycam)]

Created attachment 425839 [details]
Squashed patch with dependencies for EWS

[Cameron McCormack (:heycam)]

Created attachment 425931 [details]
Patch

[Cameron McCormack (:heycam)]

Created attachment 425934 [details]
Patch

[Cameron McCormack (:heycam)]

Created attachment 425953 [details]
Patch

[Cameron McCormack (:heycam)]

Created attachment 426087 [details]
Patch

[Cameron McCormack (:heycam)]

Created attachment 426137 [details]
Patch

[Cameron McCormack (:heycam)]

Created attachment 426168 [details]
Patch

[EWS]

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].

[Tyler Wilcock]

Reopening to attach new patch.

[Tyler Wilcock]

Created attachment 426296 [details]
Patch

[EWS Watchlist]

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

[Tyler Wilcock]

Sorry, not sure why `webkit-patch` uploaded to this bug.  Closing again.