[Webkit-unassigned] [Bug 224224] New: WebKit is inconsistent about which side to place scrollbar on (with writing-mode & direction CSS properties)

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=224224

            Bug ID: 224224
           Summary: WebKit is inconsistent about which side to place
                    scrollbar on (with writing-mode & direction CSS
                    properties)
           Product: WebKit
           Version: Safari 14
          Hardware: Unspecified
               URL: https://bugzilla.mozilla.org/attachment.cgi?id=9213617
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Layout and Rendering
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: dholbert at mozilla.com
                CC: bfulgham at webkit.org, heycam at apple.com,
                    simon.fraser at apple.com, zalan at apple.com

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210406/43ea1e76/attachment.htm>