Open Bug 1677583 Opened 5 years ago Updated 2 years ago

Firefox does not reverse scroll direction for user input when y-axis is CSS-transformed, WebKit and Blink do.

Categories

(Core :: Layout: Scrolling and Overflow, defect, P3)

Product:
Core
Component:
Layout: Scrolling and Overflow
Type:
defect

Tracking

()

People

(Reporter: twisniewski, Unassigned)

References

(
URL
)

Details

As showcased at https://codepen.io/mullsork/pen/dyXdENX, when a scrollable element is vertically flipped with transform: scaleY(-1), Blink and Webkit will also reverse that element's scroll direction (for instance, when finger-scrolling upward on a touchpad on OSX, the element scrolls up instead of down). I'm not sure if there is a standard for this, but it may cause interop issues.

I can repro this, but personally I think Blink is wrong here. Its behavior is even buggy, scrolling the flipped element via touchscreen unexpectedly toggles the direction whenever the action happens (so the same swipe-up action can scroll it up and then down).

Anne, what do you think?

Flags: needinfo?(annevk)

It does seem weird, especially as the scrollbar is still drawn in the same way. I would suggest to raise this with the CSS WG and file bugs against Chromium and WebKit to determine whether this is intentional as it seems to be mostly bad for end users (in that it is confusing UI). Moving this to Layout for now as CSS is involved.

Component: DOM: UI Events & Focus Handling → Layout: Scrolling and Overflow
Flags: needinfo?(annevk)

Hello, I'm the original reporter. I first assumed that this must be a bug in Chromium & Webkit because the behavior makes no sense to me. I reported it to Chromium here https://bugs.chromium.org/p/chromium/issues/detail?id=1139881#c4

Oops, resetting severity as it's not in DOM anymore.

Severity: S3 → --
Webcompat Priority: ? → P3

Scroll directions seem to be the same now for me in Linux between Chrome and Firefox with my mousewheel, but two-finger scrolling on my Macbook does not flip the direction on Firefox as it does on Safari and Chrome, so there is still an inconsistency here.

However, since there is no actual known webcompat fallout from this, let's unset the webcompat priority here for now.

Type: enhancement → defect
Webcompat Priority: P3 → ---

Given that there's no known web compat issues, it's P3:S3.

Severity: -- → S3
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.